-
Notifications
You must be signed in to change notification settings - Fork 470
[uBlock] Content scripts for cosmetic filtering active despite page being whitelisted #144
Comments
Sorry but this makes no sense. I think you are assuming how uMatrix work, and drawing conclusions from these (erroneous I suspect) assumptions. The counter updates lazily, only when network requests have not been seen for a set time. Something else is slowing down your Gmail, and it can't possibly be uMatrix's counter. Just because the counter updates as you type is no proof of causation. I just tried to type a mail in Gmail, with uMatrix ans all was fine. There were XHR requests, but not enough to qualify as "large number" in a short time. So I can't reproduce what you are talking about, I can't make sense of it either given that I know how things work internally. You ask me to change the code and yet you do not show any proof that there is a problem with uMatrix, just an hypothesis based on whatever assumptions you are making about uMatrix. First, please share your assumptions about how you think uMatrix works. |
I do not have any assumptions whatsoever about how I think uMatrix works internally, so there is nothing to share in that regard. I installed it and it generally works well. GMail is now also operating slowly as described above, which did not happen previously.This seems to have started recently, at approximately the same time I installed uMatrix. I cannot say for sure that uMatrix is the cause, but I also cannot rule it out. I notice that on most sites, uMatrix shows a count of perhaps 30 or 40 or even 100 connections, and that these counts do not typically change while using the site. I notice that on GMail, unlike all other sites, it shows thousands of connections after a short time, and moreover that the counters continually increase while actively using the site. It is not illogical to hypothesize that these are related. I will now try disabling uMatrix entirely and using GMail again to see what happens. It could be that some particular interaction between uMatrix and other plugins is the cause. It may also be unrelated to uMatrix. |
One thing I would look at is the dev console of Gmail, and the dev console of whatever extensions you have installed -- including uMatrix, and see if any of them is throwing exceptions non-stop. |
I have just conducted a few experiments. Disabling the uMatrix extension and reloading the GMail page causes typing to work normally. Re-enabling uMatrix and reloading GMail causes all typing to be delayed by several seconds before appearing on screen. I repeated the process several times, with the same results. I don't know the exact mechanism at work, but it seems to be caused by some aspect of uMatrix's operation, perhaps only in conjunction with other plugins. |
When I activated the dev console, typing began working normally even with uMatrix enabled. |
What are your rules/switches when on Gmail? |
As part of my attempts to get typing to work normally, I have uMatrix disabled for all google.com domains. That is why I was surprised to see the counters incrementing frequently. After a page reload, it hits >400 connections quickly, and continues to increase. After an hour or so of light use, it's over 4,000. |
Profiling the page while typing could provide good clues as to what is hogging the CPU. Unfortunately I can't reproduce here, but my Gmail account I only use once in a while to test extensions, I suppose yours is heavily populated. |
What is the best way to profile the page? Is there some tool that will show how much CPU each extension uses? |
I usually just launch a profile session from the dev console of the page. The results often look messy but I can easily tell whether the top most contributor is uMatrix/uBlock or not, by looking at the chain of calls. I thnik the profiling data can be saved and I could restore it on my side. |
Just linking these here for reference: gorhill/uBlock#911. It does appear Gmail is often suffering from performance problem. |
OK, thanks. I will run a profile the next time I get it to exhibit the slowdown. |
I suggest this be re-opened. I ran a profile during a GMail delayed typing event (screenshot below) and found that the bulk of CPU time is spent in mutationObservedHandler at line 478 of contentscript-end.js, which seems to be a part of uMatrix. Note that this happened on mail.google.com while uMatrix was supposedly disabled for all google.com domains via the power button icon in the UI. This is a bug: the correct behavior for "disabling uMatrix for a domain" is that it should not participate in the page's rendering or operation in any way -- all the observers and other hooks should be removed entirely, not just flagged somehow to not act. CPU time spent in any uMatrix function should be 0 when it's disabled. It seems anecdotally that this only happens when the badge event count on the uMatrix icon is high (approximately 4k or higher), though this may be a coincidence. |
That's not uMatrix, that's uBlock. And by the look of it, version 0.9.2.3, not the latest one. It does look like it's spending an inordinate amount of time collating the classes. I wish I could step into the code. One thing which could be interesting to find out is the total number of elements with a class attribute on the page when the problem occurs. Typing the following at the dev console should tell:
|
I also have uBlock installed, also supposedly disabled for *.google.com. uBlock's UI reports that it is version 0.9.3.0 Typing that into mail.google.com's console, I get:
|
3613 is typically high, but I ran benchmark on sites with such high count with no problem, and also, in the context here only the added nodes are queried, not the whole page as When you say "disabled for |
I don't know, I can't make sense much of what I see. It does appear the browser is spending a lot of time in native code land, |
For uBlock: I loaded mail.google.com, then clicked the uBlock icon, then its big "power button" icon, so that it and the uBlock icon both turned grey. The status line now reads "0 or 0%". For uMatrix: I loaded mail.google.com, then clicked the "power button" icon to disable it. When this didn't fix the problem, I clicked the "mail.google.com" box and changed it to "google.com," in the hopes that the more expansive scope would fix it. |
Did you reload the page afterward? If the page is whitelisted, uBlock is not supposed to run the code I see in your screenshot. |
Yes, I've reloaded the page many times. I turned uBlock and uMatrix off for GMail months ago. I've also restarted the browser and rebooted my computer many times since then. |
Testing on my unused Gmail account (it's full of emails as I used the email address on various sites just to get stuff), I get 7068 elements with a What other extensions you have installed, if any? |
How much memory do you have? Any possibility that your computer was swapping memory because of low memory condition? |
I have 8 gigs of RAM and was not doing anything particularly memory intensive at the time (as far as I know.) Do uBlock / uMatrix themselves consume a lot of memory? The next time I can reproduce the condition again, I'll check for swapping explicitly. |
Depends, as said in another issue: #147. This user too had 8 GB. The thing is, Chromium does indeed consume a lot of memory, and often it takes a while to be garbage collected -- you kind of have to force it as seen in the benchmark in the above issue. Chrome is certainly even more memory hungrier than Chromium because it has internal extensions which Chromium does not have by default. In the above issue, the hidden |
The other issue is that uBlock and/or uMatrix are apparently still doing something even though I have disabled them both for GMail. Is this a legitimate bug? |
Yes, I want to look into this. |
I confirm that the content script taking care of cosmetic filtering can end up lingering in the page even when a site is whitelisted. It's because all is asynchronous, so sometimes the information needed by a content script that it should abort is not available at the time it is checked. Solution is to check every time the content script receives an answer from the background page. Fix will be in next release (also in next dev release) |
GMail makes a large number of XHR requests, several per second. uMatrix counts them all, which leads to a very noticeable and annoying delay of several seconds while typing between the moment a key is pressed and when it appears on the screen.
Disabling uMatrix even for the entire site makes no difference, since it continues counting the XHR requests even when disabled.
Please change it to not count requests when it has been disabled for a site, or to have the option of disabling the counts for certain domains or grid squares.
The text was updated successfully, but these errors were encountered: