uBO intermittently don't block scripts

[cae3uax]

I want to block ANY script from executing, so I have added the following rules to "My rules", everything else is default:

* * 1p-script block
* * 3p-frame block
* * 3p-script block
* * inline-script block

However, intermittently uBlock Origin still allow scripts to run. I notice this when
opening Firefox and see that Google autocomplete is working, a feature that requires
Javascript.

If I open the logger and type something in the Google search field, xhr is
printed as the type of request. If the page is reloaded, scripts are blocked as
expected.

I'm using Firefox 61.0.1 and uBlock Origin 1.16.12, but I have seen this behaviour
across multiple versions of both Firefox and uBlock Origin.

[uBlock-user]

Put back the template and fill in all the requested info.

[gorhill]

when opening Firefox and see that Google autocomplete is working

Probably a duplicate of gorhill/uBlock#1327.

[uBlock-user]

I was just going to tag it with that bug.

[cae3uax]

Yes, this is the same issue I was experiencing.

I tried to enable extensions.webextensions.background-delayed-startup and after restarting Firefox first time after the change, scripts on the hompage was executed like uBO was disabled, but restarting Firefox again seemed to fix the problem and after many test with opening and closing Firefox I have not had any scripts execute.

On other machines I have tried setting suspendTabsUntilReady to true i uBO and this also fixes the problem.

I don't know what the best fix is, but both methods seems to work.

[uBlock-user]

suspendTabsUntilReady is experimental, so it may or may not work at times. Firefox's fix should take care of this for itself, but there's no such fix for Chromium yet.

[gorhill]

I am pretty sure Firefox's fix does not specifically fix the issue for uBO, as uBO never tells Firefox when all its filter lists are loaded. The fix is probably that uBO is guaranteed to be launched after uBO has been launched. If so, suspendTabsUntilReady is the real fix -- it means now it will work as intended with Firefox.

[huubert]

This is still not fixed. I tested with:

• all combinations of these settings:
  • suspendTabsUntilReady
  • extensions.webextensions.background-delayed-startup
• left one tab open: http://127.0.0.1:8000/icon38@2x.png (local http server)
• added this filter: ||127.0.0.1^
• cleared all history before reopening Firefox

When I reopen Firefox, it will load the image:
https://i.imgur.com/PLYVJPD.png
...and a few seconds later, uBlock will reload the page and block it:
https://i.imgur.com/xQznZ7D.png
...but the request was definitely sent:
https://i.imgur.com/9oxd3hX.png

[uBlock-user]

The setting is experimental, it may work and may not due to race condition.

[huubert]

Yes, I understand that. I tested it myself because there's a lot of information that may lead people to think that it's fixed (including a Firefox update), when it's not.

The only workaround I know of is to just leave an open tab (about:blank, about:home, about:newtab, whatever) selected when closing Firefox, so that in the next session that will be the active tab, and not one with content that should have been blocked.

[uBlock-user]

The only workaround I know of is to just leave an open tab (about:blank, about:home, about:newtab, whatever) selected when closing Firefox, so that in the next session that will be the active tab

or simply don't restore your session, restoring your session causes the race condition to trigger in all browsers and they simply don't wait for extensions to load. This behaviour, unfortunately, is by-design.

Until the browser-devs fix it as mentioned in the wiki, do not consider it to be fixed.

This issue in particular is invalid because the race condition prevented uBO from doing what it was supposed to do, so not a uBO issue but rather another browser issue mentioned by gorhill is the cause.

[uBlock-user]

Duplicate of gorhill/uBlock#1327

[gwarser]

I just recently read about this here https://bugzilla.mozilla.org/show_bug.cgi?id=1501159#c2
Blocking should work, but listener must be registered in top level of background script (before any async operation) and "await" for settings.

[gorhill]

listener must be registered in top level of background script (before any async operation) and "await" for settings.

This is what uBO is doing if suspendTabsUntilReady is true: https://github.com/gorhill/uBlock/blob/6d9382a5017e0d32de27562e3c8d678365d14283/src/js/traffic.js#L1153.

[gwarser]

I try commenting out vAPI.net.removeListener('onBeforeRequest', onBeforeReady); - listener cannot be persistent if is removed (?). Now, most of the time I get "listener not re-registered" error:

That error means that the extension did not call addEventListener in the top level scope of the background page. Top level scope execution finished, any remaining events were released and a warning logged.

https://bugzilla.mozilla.org/show_bug.cgi?id=1501159#c27

[gorhill]

The "suspend" listener is removed once uBO install the listener used for filtering. "Top level scope" means the listener is added not through an event, which is what uBO is doing. Don't modify the code and see if uBO is blocking early requests -- uBO will report early requests blocked in browser console (Firefox) or its own console (Chromium).

[gorhill]

I get a "listener not re-registered" in browser console at launch (when using --jsconsole).

I am going to have to read this bug entry to understand what I need to do -- I thought I had to only register a listener early...

[gorhill]

A bit clearer here: https://bugzilla.mozilla.org/show_bug.cgi?id=1503721.

My understanding is that uBO should not add/remove a listener which purpose is specifically to handle early requests and nothing else -- it has to be added and never removed.

[gorhill]

No matter what, I am not able to get rid of the error message (Nightly) -- I register a global listener at the global lexical scope and never remove it, still:

listener not re-registered ExtensionCommon.jsm:2158
  clearPrimedListeners    resource://gre/modules/ExtensionCommon.jsm:2158:24
  onManifestEntry/<    chrome://extensions/content/parent/ext-backgroundPage.js:77:7
  InterpretGeneratorResume    self-hosted:1255:8
  next    self-hosted:1210:9 

[gwarser]

This snippet blocks early requests if put inside background.JS or if linked in first script tag in uBO background.html

browser.webRequest.onBeforeRequest.addListener(
    (details) => {
        console.info('My suspend tab %d, block %s', details.tabId, details.url);
        return { cancel: true };
    },
    { urls: [ 'http://*/*', 'https://*/*' ] },
    [ 'blocking' ]
);

It does NOT work for URLs specified in command line (but works for subresources). Works for pages resumed from previous session.

[uBlock-user]

Back a versions ago (Chromium 55 to 60 I guess), if suspendTabsUntilReady was set to true and lets say you set a url to be opened immediately upon startup, I was met with this page illustrated below(baidu.com for example) -

That behaviour was perfect and no connection was made, but for some reason went away and no longer happens, can this behaviour be brought back ?

[gorhill]

Blocking whole document was causing gorhill/uBlock#3130.

[uBlock-user]

That was affecting Firefox only though..

[uBlock-user]

Could you add parameter in the setting which can be set via advanced settings so as to bring that behaviour ?

Something like suspendTabsUntilReady true, strict-block

[gwarser]

My code snippet should block everything unconditionally - something is wrong in Firefox.

Interesting thing - ABP seems to work fine on startup. Of course they don't support "document" blocking, but all subresourcess (except iframes?) seems to be blocked. They do this in different way - with my snippet I see requests in browser console, but no "200 OK" status (just nothing and empty response) - In APB logger does not show requests. Edit: hmmmm, no, this was only for URLs from command line.