Clarify position about the version for MV3 WITH webRequestBlocking (policy managed extensions)

[zb3]

I see that discussions about the impossibility to implement the full uBO using MV3 center around the removal of the webRequestBlocking API and its replacement with some (perhaps deliberately) limited DNR API.

But.. so called "policy" extensions (those installed through ExtensionInstallForcelist) can still use the webRequestBlocking API, even in the new manifest version.

I could not find:

• whether there's anything else in MV3 that makes uBO impossible
• whether the support for webRequestBlocking in policy managed extensions is meant to be temporary (the commit dates to 2020)

so I'd want to ask about it here..

Because at least on linux, installing an extension as a policy managed extension is not an issue, it's a matter of editing some system files and I'd even envision that one day you could install such extensions via system package managers (something like sudo dnf install chromium-ublock-origin).

[gorhill]

can still use the webRequestBlocking API, even in the new manifest version.

No, MV3 does not support webRequestBlocking.

[zb3]

This doesn't apply to policy extensions, see here:
https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/api/_permission_features.json;l=783

[gorhill]

That's news to me:

webRequestBlocking

Required to register blocking event handlers. As of Manifest V3, this is only available to policy installed extensions.

uBO also requires tabs.executeScript, which is no longer documented. scripting.executeScript is not a proper replacement.

I can't realistically continue to try maintaining a version for Chromium-based browsers once support for MV2 is completely removed. I can still do so for Firefox and other compatible Gecko-based browsers.

[r58Playz]

The missing tabs.executeScript behavior in scripting.executeScript can be implemented with userScripts.execute: https://github.com/r58Playz/uBlock-mv3/blob/master/platform/chromium/patches.js#L55-L73

However it requires the user to manually toggle "Enable User Scripts" in the extension settings.

I have tested this "fix" and it seems to work for at least the YouTube adblock scriptlets.

[SunsetArchon]

That's news to me:

webRequestBlocking
Required to register blocking event handlers. As of Manifest V3, this is only available to policy installed extensions.

uBO also requires tabs.executeScript, which is no longer documented. scripting.executeScript is not a proper replacement.

I can't realistically continue to try maintaining a version for Chromium-based browsers once support for MV2 is completely removed. I can still do so for Firefox and other compatible Gecko-based browsers.

I think I see what you mean when you say scripting.executeScript is not a proper replacement.

scripting.executeScript utilized the injectImmediately property of the provided injection details to vaguely determine when it's executed.

Whether the injection should be triggered in the target as soon as possible. Note that this is not a guarantee that injection will occur prior to page load, as the page may have already loaded by the time the script reaches the target.

There is no guarantee that the injected content script will run first, or in uBlock's case, no guarantee it will run in a tab before what it needs to block. Nor is there a definitive means of ordering the execution of certain content script injections.

tabs.executeScript utilized the runAt property of the provided injection details to minutely define the point in which the script should be executed. According to Mozilla documentation of extensionTypes.RunAt:

Values of this type are strings. Possible values are: "document_start", "document_end", "document_idle".

• "document_start": corresponds to loading. The DOM is still loading.
• "document_end": corresponds to interactive. The DOM has finished loading, but resources such as scripts and images may still be loading.
• "document_idle": corresponds to complete. The document and all its resources have finished loading.

The default value is "document_idle".

This provided a means of guaranteeing that uBlock's injected content scripts will run either before the DOM finishes loading, before resources are finished loading, or after the document and resources have finished loading.

The timing of a content script's execution is crucial to an extension's ongoing operation. The unreliability of scripting.executeScript makes it so that B can be executed before A, even though B functionality is dependent on A executing first. The transition from runAt to injectImmediately feels ill conceived in every way.

These are content scripts that must run as soon as possible, so deferred execution to enforce execution order is not a viable solution.

The only way I see the dynamic content script parts of uBlock working in a small subset of cases is having a generalized content script that can be statically registered so it can use the runAt property, and utilize chrome.storage to store and load the parameters needed to facilitate its execution. But that would go against uBlock's goal of not being computationally heavy due to all the serialization that would occur, so that's not entirely viable either.

I can see why maintaining uBlock Origin for Chromium-based browsers is such a headache, even without thinking about webRequestBlocking.

[gorhill]

utilize chrome.storage to store and load the parameters needed to facilitate its execution

chrome.storage.*.get is asynchronous, however well it work depends on how long it takes for the result to be returned, the API makes no guarantee about this.

So far the only reliable way is the new userScript.register() API through the code property. This is actually the approach used by current uBO in Firefox through its scripting.registerContentScripts() API.

But anyways, there are other missing capabilities, on top of the fact that uBO was not designed from the ground up to be suspendable, probably causing some malfunctions along with the fact that reloading all filter lists in memory each time the worker is unsuspended is rather inefficient. uBOL was designed from the ground up with the assumption of being constantly suspended.

[uBlock-user]

So far the only reliable way is the new userScript.register() API through the code property.

Guessing this is not available for manifest version 2 for Chromium, correct ?