-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uBlock under e10s slows entire browser when loading pages that make many HTTP requests #376
Comments
URL? |
@gorhill The best example I have (with the 600+ requests) is a company directory with headshots, which is unfortunately private or I'd include it. Toodledo's logged-in homepage is also an offender, but if you don't already have an account with lots of tasks, that won't be very helpful for testing either. I tested it out on the NYTimes homepage, and it's it's noticeably slower, but nowhere near as drastic (ie, I can tell the difference there without using profiling tools, but I wouldn't be bothered by it if I weren't consciously looking for it). I'll try and keep an eye out for sites that exhibit this behavior and don't require a login; I know that this will be tough to test otherwise. |
Slower than what? I just tested the front page |
This looks like it's a problem with your Firefox profile, try making a new one and see if it happens. |
@gorhill To clarify, I'm not talking about how long the page takes to load. I'm talking about whether or not it prevents usage of other tabs (which have already been loaded) while the tab is loading. This is the e10s 'rendering wheel' that I'm talking about; I know Mozilla has a term for it, but I'm blanking on what it is: Under e10s, this will be displayed in the center of the tab instead of the content while waiting for the rendering process to respond. @SW1FT Yes, I'm testing this in a blank profile. These are the steps I'm taking:
When I do this without uBlock installed, the Amazon page may take several seconds to load, but it never blocks the rendering process long enough to cause a spinning wheel on the Github page. If I install uBlock and repeat steps 1-5, the Github page will sometimes display the spinning wheel briefly (less than a second) when I switch to it. For other pages, I sometimes experience this for several seconds or more, which renders all tabs on the browser unusable during this time. I wouldn't be surprised if the issue had to do with the shims that the SDK uses, which are mentioned in #214, but since the behavior here is different I believe it may be a slightly different issue. |
@ChimeraCoder This seems like something that Mozilla can help to figure out. e10s are currently under heavy development, so bugs and issue are natural. |
E10S isn't stable yet and cause alot of mess, so I think uBlock have nothing to do with it. Btw if you use adblock, it become more worst, your browser lag and stop working. |
@gorhill For some reason I can't find your last comment from the other day - was it deleted? In any case I have a strong feeling that |
Yes, I decided I would rather try the idea whenever I have time rather than speculate pointlessly about it. |
On Nightly with e10s enabled, I sometimes get a jank warning modal bar about uBlock Origin.
This might not be strictly related to @ChimeraCoder's issue because browsing seems quite smooth for me, it's probably just related to startup (rules loading?). |
@silverwind Did you disable/enable uBlock after launching Nightly? This bug causes a whole lots of CPOW warnings, unless you disable then re-enable uBlock. |
@gorhill That seemed to fix it. Sorry for not reading the docs 😉 |
Now using Nightly 42.0a1, and really I see uBlock performing very well with it -- as witnessed by
Whereas uBlock typically shows single-digit
The only synchronous messaging used by uBlock is a very lightweight one, i.e. there is virtually no waiting time[1], and in all likeliness, whatever waiting time there is as a result of Firefox synchronous messaging overhead. uBlock could easily switch to asynchronous messaging IF ever there is API documentation which states that whatever async message is guaranteed to be processed before an HTTP observer is called. But there is no such documentation, and although I verified it seems to work in Nightly, I can't write code which relies on wishful thinking -- especially as in its current state uBlock perform excellently compared to similarly purpose add-ons. [1] content-side a synchronous message is sent to the chrome-side, and chrome-side the only thing happening is to quickly store the received data into a pre-allocated ring buffer and return immediately. So the synchronous messaging event is for all practical purpose a non-issue here. |
👏 Thanks for the results. Love your work! |
This may be related to #214, but I think it's slightly different. I've experienced this in several different versions of Firefox that are running with e10s (electrolysis) enabled.
When loading a page that makes many (e.g. 100 or more) HTTP requests on the first load, uBlock slows down the entire browser until that page is done loading, which can easily be 20+ seconds. The rest of the UI is responsive, so I can switch to another tab, but because the rendering process is blocked, those tabs also simply display the infamous "loading wheel" until the other page is done rendering.
I have one website which makes 600 HTTP requests on the first load (all images), and it renders the entire browser unusable for 30 seconds when I load it with uBlock enabled. With uBlock disabled, it loads almost instantaneously.
To note: uBlock isn't the only extension that has this problem. Similar extensions like Ghostery and Noscript also cause the problem as well, and the problem is much worse if more than one of these extensions is installed simultaneously. But since the problem is noticeable even when uBlock is the only extension installed, it seems to merit filing a ticket here. I mention the other extensions only because there is likely significant overlap between users of these extensions, and for them, the issue will be compounded.
The text was updated successfully, but these errors were encountered: