uBo causes typing lag on certain webpages #1687
Labels
Chromium
specific to Chromium/Chrome
external
issue involving an external factor
unable to reproduce
cannot reproduce the issue
Comments
|
Speculated performance issues will be marked as invalid and closed if they do not come with actual profiling data from Firefox Profiler/Chromium Profiler + fully substantiated analysis supporting the claim. |
|
Sorry, the profiler is attached. Is there anyway to re-open it? Thanks. A Gif to show it too: Without uBo: With uBo:
|
uBlock-user
added
unable to reproduce
|
After some further testing, it look like disabling Easylist can eliminate the issue (despite no rule is actually triggered. I guess it's simply its huge amount of rules.) |
Number of rules never been a problem for uBO, the second gif displays the lag which is only experienced when you have another software running or another extension hogging the CPU concurrently. I don't see this issue either Firefox or Chromium. |
|
Well, I followed the guide and use a new profile with only ubo extension. Simply "disable on this site" would be enough to eliminate the issue, I don't even need to disable uBo (even though I did in control group). I can see it probably won't be easy to reproduce on a beefy computer, but the issue is indeed caused by uBo+Eayslist combination here on my computer by controlling the variables. |
|
I can't reproduce such issue with uBO + default settings and (up to date) lists. The profiling data show all the time is spent in "Recalculate style", which is browser code -- I see nothing for uBO. See if disabling cosmetic filtering make the issue disappears. If so, then I suspect there might be a highly generic cosmetic filter in EasyList which is causing an issue on this page, but only on your side, maybe as a result of graphic driver issues, something you will have to investigate. If a highly generic cosmetic filter is causing you issue, you should have the same problem with AdGuard or ABP, which you may try without uBO to validate whether this is the issue. |
|
|
I tried to bisect it, but it looks like that it's not any specific rule, but the existence of any of these generic cosmetic rules will gradually affect the performance.
|
|
Never mind, using the other half of all these Feel free to close this issue if you guys feel like nothing needs to be added. Or let me know if you want anything from me. Cheers! |
|
You can just disable cosmetic filtering, that will help, but I feel it's not normal that you browser can't cope with the generic cosmetic filters, the issue would be more widely reported if it was affecting everybody, I feel there is something specific on your system at the root of it -- there was 8 seconds of "Recalculate style" out of 14 seconds in your profile, this is just not normal (I don't have a "beefy" computer, so I would be able to reproduce something if this was the reason). |
|
Yeah that's a possibility. It's worth noting that I never encountered such issue on other sites, and even on the same |
|
Oh, and I don't have such problem on Firefox (just did a quick test with my main profile, so with all kinds of other extensions). |
|
Here are the cosmetic filters injected unconditionally by uBO, there are 1023 of them (deemed "highly generic" by uBO), so this might be easier to bisect than trying out all of EasyList's generic cosmetic filters -- if you are still curious as to which one(s) is causing this issue: Highly generic cosmetic filters |
Instead of disabling any lists at all, you can add |
|
As per the discussion, this sounds more like a browser issue as gorhill points out in - #1687 (comment), so I doubt anything can be fixed here. |
uBO won't report cosmetic filters in the logger if the elements that would have been blocked were removed from the DOM by the site code itself(done by anti-adblock scripts sometimes, I don't believe that's the case here.) |
|
I don't think any filter is actually triggered (hence no log, if I understand what you mean correctly), just the process of checking them causes this performance issue on Chrome. In my previous bisect attempt using the ~1000 "Highly generic cosmetic filters" (similar to what gorhill lists but not exactly the same), I can reproduce the issue with either half of it. And further reducing the number of rules applied will make it gradually better and better. |
|
@fireattack does this issue only occur at |
Yes, I can explain. The list of filters I posted above are deemed "highly heneric" (1,023 with default lists), and uBO injects unconditionally such filters. The logger does not report those filters because none are matching anything in the DOM. For the "lowly generic" (currently standing at 22,167 with default lists), uBO injects only those for which there is a match in the DOM -- which means zero on that page. Keep in mind that AdGuard and ABP injects all highly and lowly filters unconditionally, not just the highly generic ones The logger reports only those cosmetic filters which were found to have an effect on a page, i.e. for which there was a match. I see this page makes use of a lot of |
|
I consider it's a browser issue given that:
Given this, I am pretty sure Chromium devs would want to understand the cause of this as this makes Chromium look bad compare to Firefox. |
So far yeah, I only see this on |
|
A quick update: I have noticed similar issues more and more on other sites, especially heavy sites like Amazon and Twitter. It often causes all the interactions to be "laggy", including typing, context menu, and scrolling. I don't know if it's a different issue or still the same (since it can also be eliminated by disabling cosmetic filtering), so I don't want to open a new issue. A performance profile I recorded on Amazon.co.jp (visiting this url) below in case anyone wants to have a look. Profile-20220131T022822.json.txt Thanks! |
|
It's the same as was found above, that page is spending a huge amount of time in recalculating styles, including as the mouse move. uBO's own code is not the issue here. Since there are no other report of such issue, please share the troubleshooting information at the bottom of Support pane, it seems something very specific to you is occurring on your side. |
|
Thanks for confirming, I would see if I can report it to chromium or Amazon. |
|
Some sites do not like to have certain of their resources blocked, so if you misconfigured uBO with bad filters/rules/lists, this could be the cause -- hence why I asked to share troubleshooting information. Beyond this, did you enable experimental features in |
Above is with my main UBo settings. I tried to reset to default and the problem persists. It does become somewhat better if I disabled all the other extensions, but that's kinda expected. As for flags, I don't think I disabled any relevant ones; but it's a relatively outdated computer.
|
|
I think it would be worth for you to create a new browser profile and test again with only default settings in both Chromium and uBO with up to date list -- do not add/remove any lists, do not add any filters/rules -- see if the issue is still there. |
|
Can reproduce in a new profile with Chrome Canary, with nothing but uBO dev build in all default. The responsiveness is better than my heavy main profile, but still noticeably laggy. |
|
Seems worst than the previous profile -- I see a huge amount of time spent in Amazon's own code which seems to be jQueryUI, more specifically most time is spent in a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Prerequisites
I tried to reproduce the issue when...
Description
When uBo is enabled, typing in text area becomes very laggy.
A specific URL where the issue occurs
https://bugs.chromium.org/p/chromium/issues/detail?id=534732
Steps to Reproduce
Expected behavior
They letters get on the screen immediately as you type.
Actual behavior
The whole typing experience is very laggy. You wee see sometimes the letters only start to appear after you typed like 15+ letters.
uBlock Origin version
1.37.2
Browser name and version
Google Chrome 92.0.4515.159 (Official Build) (64-bit) (cohort: 92_win_159)
Operating System and version
Win7 x64
The text was updated successfully, but these errors were encountered: