uBlock applying blocking rules for websites it is turned off

[ParticleCore]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

This issue is in keep with recent user reports on social media stating that even after turning off uBlock for a specific website it is still being detected, very likely as a direct result of this bug that is causing the extension to still apply blocking rules for websites it was turned off.

Currently using uBlock 1.55.0 with default settings and rules on Firefox 121.0.1 and 123.0a1

I have it turned off for youtube.com, for example

I have created a brand new profile with the only extension installed being uBlock

With uBlock turned off for youtube.com the ads are still being blocked

Debugging the page confirms that it is still injecting blocking rules:

Disabling the extension in the browser addon manager and refreshing youtube resolves the problem, no more blocking rules appear in the website.

A specific URL where the issue occurs.

https://www.youtube.com/watch?v=oACoGd4AZwk

Steps to Reproduce

Install uBlock on a fresh profile
Open any url video
Open the debugger and look for the scriplet blocking rules

Expected behavior

When uBlock is turned of for a specific website no blocking rules should be applied

Actual behavior

When uBlock is turned of for a specific website, blocking rules are still being applied

uBO version

1.55.0

Browser name and version

Firefox 121.0.1 and 123.0a1

Operating System and version

Windows 10

[gorhill]

Unable to reproduce, when I turn off uBO and reload the Youtube page, I don't see any uBlockOrigin +js() scriptlets in the debugger:

uBO enabled:

uBO disabled and page reloaded:

What is your "4 results" screenshot showing? How did you get this?

---

Similarly I cannot reproduce with a simpler scenario:

• Add example.com##+js(set, ubo, true) in "My filters"
• Open http://example.com/
• Open dev console
• Verify that ubo is true
• Disable uBO, reload page
• ubo is undefined

[gwarser]

Injected scriptlets will not disappear if you navigate from one video to another. YT is a long living page - content is dynamically updated by JS, you need to manually reload or open in new tab to load fresh scripts without modifications.

[gorhill]

Regarding the issue with a link to here:

In order to confirm if Iridium is the reason for any slowness/lag/performance issues on YouTube

Firefox has a good profiler tool to sort out performance issues: https://profiler.firefox.com/

I did experience at some point what appeared to be performance issue in Firefox, with no extension enabled. I submitted a profiling session, see https://bugzilla.mozilla.org/show_bug.cgi?id=1874862.

More such profiling data need to be submitted if we want this issue to be investigated by Firefox devs.

[ParticleCore]

Unable to reproduce, when I turn off uBO and reload the Youtube page, I don't see any uBlockOrigin +js() scriptlets in the debugger:

uBO enabled:

uBO disabled and page reloaded:

What is your "4 results" screenshot showing? How did you get this?

Similarly I cannot reproduce with a simpler scenario:

* Add `example.com##+js(set, ubo, true)` in "My filters"

* Open `http://example.com/`

* Open dev console

* Verify that `ubo` is `true`

* Disable uBO, reload page

* `ubo` is `undefined`

Does not happen all the time, in my test runs (about 50) it happened 80% of the times. Will keep an eye on it to see if there is a way to trigger it.

[ParticleCore]

Injected scriptlets will not disappear if you navigate from one video to another. YT is a long living page - content is dynamically updated by JS, you need to manually reload or open in new tab to load fresh scripts without modifications.

Although I did not explicitly stated in the first steps, I did force refresh every time in between toggling the setting in uBlock

[ParticleCore]

Regarding the issue with a link to here:

In order to confirm if Iridium is the reason for any slowness/lag/performance issues on YouTube

Firefox has a good profiler tool to sort out performance issues: https://profiler.firefox.com/

I did experience at some point what appeared to be performance issue in Firefox, with no extension enabled. I submitted a profiling session, see https://bugzilla.mozilla.org/show_bug.cgi?id=1874862.

More such profiling data need to be submitted if we want this issue to be investigated by Firefox devs.

Did consider that, but as soon as uBlock was disabled in the addons manager the performance issues were gone. Unless the browser itself was causing the issues while the extension was enabled, then I can't think of any other way to explain it.

Was not able to correctly confirm (YT scripts keep changing every now and then) but the behavior of that issue made me believe that the way uBlock was tampering with the ad data on the website was causing the YT scripts to enter into a error/retry loop which would eventually time out, causing the video to stop loading and show the circle icon on the video.

From my experience playing with their code, it felt like part of their ad logic has instructions on how many are loaded and when to show an ad, and when it tries to pull the information for that ad (say 30s into the video) it never finds it, but since it is expecting to find something then it stays in that suspended state forever.

Problem is, since their scripts keep changing almost daily, and with it some of their logic, it is hard to pinpoint the actual issue.

[stephenhawk8054]

You need to provide profiler data if you see performance issue. Otherwise, there's nothing to investigate.

[gorhill]

as soon as uBlock was disabled in the addons manager the performance issues were gone

If you experience performance issue you think are caused by uBO, please provide profiling data, just presuming doesn't lead anywhere except endless misdagnosis.

[gorhill]

Does not happen all the time, in my test runs (about 50) it happened 80% of the times

What is the test run? You (enable uBO => reload page => disable uBO => reload page) repeatedly? Or do you just disable uBO once then reload repeatedly?

[ParticleCore]

What is your "4 results" screenshot showing? How did you get this?

Forgot to address this. When the issue started happening I noticed the ad data was gone, when I tried to inspect it I stumbled on the ad data points overridden with constants, which then led me to those scriplets still running after the extension was turned off for that website and still persisted after page refresh. Only after disabling the extension in the addons manager the scriplets were no longer present.

Just searched for parts of the code to try figure out where it was coming from, nothing special:

If you experience performance issue you think are caused by uBO, please provide profiling data, just presuming doesn't lead anywhere except endless misdagnosis.

Sorry, hard to scope that one. The lag occurs briefly in the first few seconds of the video playback until it hits the 30s-ish mark then the video stops playing, does not buffer anymore, and the loading circle shows up on the player and stays like that. Most of the times when I am fast enough, I can tell when the issue is happening by checking in the player stats for dropped frames, it always drops frames when the issue occurs.

I don't believe the performance problems are being caused by uBlock directly, but I do believe its scriplets/code modifications made by it induces the YT code into a state that causes performance issues, at the very least with the YT scripts that were loading for me at that time.

What is the test run? You (enable uBO => reload page => disable uBO => reload page) repeatedly? Or do you just disable uBO once then reload repeatedly?

Open YT
Install uBlock
Refresh YT
Turn off uBlock for YT
Reload YT
disable uBlock for YT

Sometimes it looks like the issue is not happening in the first 30s, but some of those times it happens 1:30s in. This one just happened right now (with uBlock enabled for YT) to me, and stays like this:

Relevant YT scripts loaded for the above specific test are as follows:

player https://www.youtube.com/s/player/787e9b63/player_ias.vflset/en_US/base.js
ui builder https://www.youtube.com/s/desktop/80338919/jsbin/desktop_polymer.vflset/desktop_polymer.js
navigation https://www.youtube.com/s/desktop/80338919/jsbin/spf.vflset/spf.js

Those might change at any time though, but just in case they can be helpful I included them here.

[stephenhawk8054]

Profiling data means using https://profiler.firefox.com/

[ParticleCore]

Profiling data means using https://profiler.firefox.com/

I meant to say it is hard to pin the performance issue on uBlock since it is most likely YT that is having performance issues as a result of uBlock modifications.

[stephenhawk8054]

That's why you need profiler data. It will show what the website is loading. It's NOT just for pointing the issue to uBO.

[gorhill]

Alright I am going to try to gather all the detailed steps to repro in one place, tell me if I get this right:

1. New Firefox profile
2. Open https://www.youtube.com/watch?v=oACoGd4AZwk
3. Install uBO
4. uBO should be enabled for YT (default after install)
5. Reload the YT tab
6. Disable uBO for youtube.com
7. Reload the YT tab
8. Let the video play

Result: Eventually issue when repeating 1 to 8? Or is it 4 to 8?

Correct?

[ParticleCore]

Alright I am going to try to gather all the detailed steps to repro in one place, tell me if I get this right:

1. New Firefox profile

2. Open `https://www.youtube.com/watch?v=oACoGd4AZwk`

3. Install uBO

4. uBO should be enabled for YT (default after install)

5. Reload the YT tab

6. Disable uBO for `youtube.com`

7. Reload the YT tab

8. Let the video play

Result: Eventually issue when repeating 1 to 8? Or is it 4 to 8?

Correct?

The current issue for which I opened was the uBlock modifications were still being applied after it was turned off via this setting:

And refreshing YT afterwards.

The other issue that made me find this was the performance issue, which was happening almost every time I opened YT with uBlock on (or off, but the blocking rules were somehow still being applied to YT).

Unfortunately I am now having a hard time making it happen again after trying to use the profiler recorder.

One last thing is yesterday this was not a problem at all, I worked for over 12h and never noticed this happening once using the exact same setup as I used today - uBlock was working correctly, no YT performance issues and no blocking rules were "sticking" on the website after turning it off in uBlock.

[ParticleCore]

I did experience at some point what appeared to be performance issue in Firefox, with no extension enabled. I submitted a profiling session, see https://bugzilla.mozilla.org/show_bug.cgi?id=1874862.

Beginning to wonder if it is all tied to that one somehow.

[gorhill]

And refreshing YT afterwards

The part that is not clear is you said:

in my test runs (about 50)

What were the exact repeated steps in these runs? It's what I am trying to figure before spending time to try and reproduce the issue.

[ParticleCore]

And refreshing YT afterwards

The part that is not clear is you said:

in my test runs (about 50)

What were the exact repeated steps in these runs? It's what I am trying to figure before spending time to try and reproduce the issue.

Apologies, that completely went over my head.

1. Opened Firefox with a temporary new profile
2. Opened YT
3. Installed uBlock
4. Refreshed YT
5. Confirmed uBlock is blocking the ads
6. Turned off uBlock for YT
7. Refreshed YT
8. Scriplets still showing in the debugger, ads being blocked as a result
9. Disable uBlock in the Firefox addons manager
10. Refreshed YT
11. Ads no longer being blocked and scriplets no longer show in the debugger

So for me this is basically what I see:
uBlock enabled and opening YT, can confirm the scriplets are present

Turn off uBlock for YT

Refresh YT (notice the blue icon in the refresh button in sources search, those results are in cache despite refreshing YT)

Search for the scriplets again (no longer cached search results) and they are still present

[gorhill]

Thanks. So if I can't reproduce the first time, which steps do I repeat to try to reproduce it again? 1 to 10? Or a subset of these steps?

[ParticleCore]

Thanks. So if I can't reproduce the first time, which steps do I repeat to try to reproduce it again? 1 to 10? Or a subset of these steps?

Usually just enabling uBlock, refreshing YT, disabling uBlock, refreshing YT was sufficient for most cases.

[gorhill]

Are you refreshing your search after you reload the page? If I reload the page after I disable uBO without refreshing the search term (I delete the last s than add s again), they stay there, the browser doesn't re-search on its own. If I force a re-search, the result is empty.

[ParticleCore]

Are you refreshing your search after you reload the page? If I reload the page after I disable uBO without refreshing the search term (I delete the last s than add s again), they stay there, the browser doesn't re-search on its own. If I force a re-search, the result is empty.

Yes, that is what I meant by the blue icon in the images, when that icon is showing then those results are cached from a previous load, the search must be done again in order to confirm the scriplets are there or not after refreshing the page.

[gorhill]

I tried tens of times and still can't reproduce. Maybe it's a timing issue and my PC is not as fast/slow as yours? What's the rough specs of your PC?

---

If scriptlets are still injected after disabling, I would think the issue is in the content-script registering code. This is where content scripts are unregistered when uBO is disabled for a site:

https://github.com/gorhill/uBlock/blob/1.55.0/src/js/scriptlet-filtering.js#L103-L109

[ParticleCore]

I tried tens of times and still can't reproduce. Maybe it's a timing issue and my PC is not as fast/slow as yours? What's the rough specs of your PC?

8gb ram
i7 11800h
Nvidia RTX 3050

If scriptlets are still injected after disabling, I would think the issue is in the content-script registering code. This is where content scripts are unregistered when uBO is disabled for a site:

https://github.com/gorhill/uBlock/blob/1.55.0/src/js/scriptlet-filtering.js#L103-L109

Any chance a specific condition might not be ironclad when it comes to injecting while checking if it is turned off for a specific website? Timing issue or a disallowed list that might not have time to populate beforehand, etc.

[ParticleCore]

In no mean I want to interrupt yours conversation, and I don't know whether the both issues are related or not, but I think it's better to inform about an old similiar issue, even if it will turn out to be unrelated to the current one, than to not inform about it, and waste a theoretical possibility to help in the current issue :

* [Scriptlet injected on whitelisted page #2896](https://github.com/uBlockOrigin/uBlock-issues/issues/2896)

Sounds very reasonable. It does feel like the setting is being ignored for some odd reason, hopefully that will help in figuring something out, thanks.

[gorhill]

If more people can try to reproduce as per repro steps in #3083 (comment), this will help maybe identify what else is needed to reproduce.

[gorhill]

#2896 is unrelated, it was caused by not having a listener for changes to reset registered content scripts.

It's there now and I verified that it is called immediately upon disabling uBO, @ParticleCore you can verify this by putting a breakpoint at this line and verfying that it executes through this.flush(msg.hostname).

[gorhill]

When I follow the steps at this comment, signed in (which is only how I could reproduce them), I cannot reproduce with 1.55.1b11 -- so back to being unable to reproduce. There has already been a lot of wrong information regarding the steps to reproduce, until it was identified that being signed in was important. So for now I consider the issue correctly mitigated, except the know edge cases I know this could happen, which the repro steps are not.

[ParticleCore]

@gorhill Is there any way to check which hosts might be causing the rules to be applied in the current tab? For example, you found out accounts.gooogle.com was one such case, is there a way I can see for myself if there could be another one causing this when it happens again?

Edit: Adding www.gstatic.com to trusted site seems to have helped too.

[gorhill]

Firefox shows the host on my side:

[ParticleCore]

Firefox shows the host on my side:

Thank you, I will pay attention to that area if it happens again. So far after adding www.gstatic.com the issue did not return, but the same thing happened with accounts.gooogle.com and eventually came back.

[Yuki2718]

@ParticleCore What exact "issue" you're referring? Injecting scriptlet rules into accounts.youtube.com should not cause ads being blocked or detection. So if I understand correctly, the original claim has not been confirmed or reproduced by anyone other than you.

[ParticleCore]

@ParticleCore What exact "issue" you're referring? Injecting scriptlet rules into accounts.youtube.com should not cause ads being blocked or detection.

Because of that situation it affects ads on the page which it was suppose to be disabled on, and as a result it causes adblock detection as well. It means that despite appearing to be turned off for YouTube, it is infact still enabled.

[Yuki2718]

I have a Firefox profile having real anti-adb with rules to deliberately trigger detection, and can not reproduce. The current rules in uBlock filters have www., but my rules are youtube.com##+js.

Problem is, since their scripts keep changing almost daily, and with it some of their logic, it is hard to pinpoint the actual issue.

Most parts of their script has been the same, they mostly change only function names. We have been monitoring their script for more than 6 months now.

[stephenhawk8054]

as a result it causes adblock detection as well

No, when disabling uBO on www.youtube.com, the scriptlets are only injected into accounts.youtube.com now, not www.youtube.com and it would not cause any anti-adblock.

I can only see blob of the uBO scriptlets being injected into accounts.youtube.com here, not www.youtube.com

Scriptlets injected into accounts.youtube.com DO NOT affect www.youtube.com

[Yuki2718]

Coincidence AdguardTeam/AdguardFilters#170786 (comment)

So I added YouTube to the allowed list on AdGuard, however I still get the same message on YouTube,
...
and when I turned off AdGuard YouTube worked again.

[ParticleCore]

All I know is it affects YouTube even after turning it off for YouTube, and I've already shown it multiple times and when it happens the issue stops after I disable uBlock entirely. I think the recordings above are self explanatory.

Anything else beyond that is outside my ability to explain better, and unfortunately that already made the good folks here go back and forth wasting some time because I couldn't explain things better from start.

[gorhill]

I think the recordings above are self explanatory.

These recordings were using 1.55.0, which didn't get the fix here.

[gorhill]

the scriptlets are only injected into accounts.youtube.com now

@stephenhawk8054 By the way, shouldn't we exclude with ~accounts.youtube.com since I doubt the scriptlets are useful in that context.

[stephenhawk8054]

@stephenhawk8054 By the way, shouldn't we exclude with ~accounts.youtube.com since I doubt the scriptlets are useful in that context.

I agree. I'll adjust it.

[ParticleCore]

I think the recordings above are self explanatory.

These recordings were using 1.55.0, which didn't get the fix here.

Sorry, at the time yes, I will record it when it happens again with the beta version when I am home.

[ParticleCore]

I was able to record the issue happening again with 1.55.1b11

1.mp4

Steps done in the video:

1. Show current uBlock version disabled on YouTube
2. Confirm scriplets are still loaded in the page
3. Show the sources tree each result I could find
4. Refresh the page using the refresh button
5. Confirm scriplets are still loaded in the page
6. Hard refresh page using Ctrl+Shift+R
7. Confirm scriplets are still loaded in the page
8. Open the console to confirm the scriplets are indeed still modifying the ad data information on YouTube
9. Disable uBlock via the addons manager
10. Refresh the page using the refresh button
11. Scriplets are no longer loaded in the page
12. Open the console to confirm the scriplets no longer modifying the ad data information on YouTube

I hope I was able to make things cleared this time, let me know if I can help clarify anything further.

I am still unsure of what is causing this to happen because all the time now I have uBlock turned off (using the power button in uBlock) for YouTube and, for a while, the issue never occurs. Eventually it starts happening again, and I never turned it on once for YouTube.

[gwarser]

Can you turn off Stylus and test again?

[ParticleCore]

Can you turn off Stylus and test again?

It has no styles configured for YouTube though:

But I will turn it off for now.

[gorhill]

@ParticleCore Did you visit webpages with Youtube video instances embedded in them? That is one of the edge cases I am talking about when I say this cannot be completely fixed. Ideally, the contentScripts.register() would need a way to tell to not inject if the root frame is a specific hostname, i.e. www.youtube.com here.

[gorhill]

Another way to mitigate the known edge cases in the current instance would be to be explicit in the filters about which exact subdomains of youtube.com should be injected and leave out youtube.com.

[ParticleCore]

@ParticleCore Did you visit webpages with Youtube video instances embedded in them? That is one of the edge cases I am talking about when I say this cannot be completely fixed. Ideally, the contentScripts.register() would need a way to tell to not inject if the root frame is a specific hostname, i.e. www.youtube.com here.

I am 99% certain you are correct. Just opening google.com and doing a simple text search can cause a YT iframe to be injected into the search results:

And when I check YT before that happens: no issues
After that happens: the issue is there immediately

[ParticleCore]

An update; in order to correct the issue in YT there is no need to manually disable uBlock via addons manager, simply turning it on and off again works, it is way easier and faster, and seems to be enough to deregister any rogue scriplets.

[ParticleCore]

@gorhill Unsure if this suggestion is even feasible, but since toggling uBlock seems enough to resolve the issue (at least from my perspective), maybe a similar logic could be implemented whenever a website is opened? It would always ensure the correct deregistration of scriplets for websites in which uBlock is turned off. This way, even if, for example, a YT iframe from an unrelated website were to introduce the issue again, it would be mitigated by enforcing deregistration whenever YT is opened.

[gwarser]

Maybe another case: https://www.reddit.com/r/uBlockOrigin/comments/19fg0h8/ublock_origin_qwant/

[gorhill]

No way to tell without the troubleshooting information.

I won't further make changes here, it's a mitigation for the sake of not undermining people who keep uBO enabled, which I assume is the vast majority.

[ParticleCore]

Another update surrounding this topic.

I noticed today that this situation (in my case at least) depends on having opened YouTube before navigation on any other pages in order for it to surface.

Last night I opened the browser fresh and navigated to multiple websites, across different pages (google, github, news combinator, dev documents, etc.) and after a while I opened YouTube to play some music and the issue was not there at all.

However, after having YouTube opened (remember, uBlock is enabled for everything else except in YouTube) and navigating again to other websites (on different tabs), eventually the issue returned on YouTube.

So it seems to me that this issue depends on having opened YouTube (keep it open) before navigating on other tabs in order to trigger the issue, which leads me to think that perhaps there might be some sort of global listener/dispatcher that is causing the disabled uBlock extension on YouTube tab(s) to inject or schedule injection of scriplets in them which is being triggered by other opened tabs on different websites.

Basically, a tab with google search results containing a youtube iframe causes the disabled uBlock on the youtube tab to inject scriplets, if that makes sense.

I might be completely wrong tho, but that is what I can deduce from my pov.

[Yuki2718]

Again I don't know what Issue you mean, as currently uBO can't be detected by YT.

[ParticleCore]

Again I don't know what Issue you mean, as currently uBO can't be detected by YT.

Sorry, I am referring to the uBlock scriplets being present in a page where uBlock is supposedly turned off, see #3083 (comment) and #3083 (comment)

[Bertaz]

@gorhill I see you closed the issue after 2 months. Was this fixed or wontfix as per #3083 (comment) ?

I won't further make changes here, it's a mitigation for the sake of not undermining people who keep uBO enabled, which I assume is the vast majority.

If the latter, is #3083 (comment) an issue only with detection (e.g. opening a site with a example.com iframe and opening whitelisted example.com with obsolete antidetection filters causes example.com to detect uBlock via the scriplets) or the loaded scriplets also blocks the ads in the whitelisted page?