4 ms·

That doesn't really state if that's a self-imposed limitation or limitation of Mv3.

bilkow 3y ago
I've edited my comment to also include a link to the Chrome docs, but that FAQ entry also has the link to an issue in the webextensions repository indicating it's a limitation of MV3: https://github.com/w3c/webextensions/issues/112 https://github.com/w3c/webextensions/issues/112
- jsnell 3y ago
  But that issue has nothing to do with the question of whether the "filter lists" could be updated dynamically without store review. It's asking for a way of programatically triggering the update to the latest version of the extension in the store. That feature request being fixed would do nothing to enable updates without store review. And likewise the feature for doing updates of the ruleset without a store review already exists but is not used by UBOL. So the link doesn't actually support your claim of it being a limitation of MV3. The link is just irrelevant. The FAQ hints at why UBOL doens't make use of that feature, but doesn't actually state it outright.
  - bilkow 3y ago
    > So the link doesn't actually support your claim of it being a limitation of MV3. From the issue: "In Manifest V3 remotely hosted code is no longer allowed." Altought the parent was talking specifically about network requests, in which case you may be right and I missed it, but that's not the general problem. Blocking network requests is not sufficient for modern ad/tracking blocking and to be able to run effectively they need to inject scripts into the page, thus "remotely hosted code" is necessary, and the Chrome docs above says that it's not allowed.
    - jsnell 3y ago
      The new complaint in the article was about dynamic updates not being possible. That is just demonstrably incorrect, and not countered in any way by the FAQ link. But you're now trying to switch it to just a relitigation of switching to declarative blocking in general.
gorhill 3y ago
For an extension to be entirely declarative, it must package all the scripts to inject anywhere, the scripting.registerContentScript API doesn't allow injecting code as string[1], the content scripts must be part of the package.[2] There is userScripts API which allows injecting code as string, but it's impractical as in Chromium-based browsers this requires extra steps by the user to enable the API.[3] In Firefox, the documentation for this API has the following note[4]: > When using Manifest V3 or higher, use scripting.registerContentScripts() to register scripts * * * [1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/registerContentScripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... [2] https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium/rulesets/scripting https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium... [3] https://developer.chrome.com/docs/extensions/reference/userScripts/#concepts-and-usage https://developer.chrome.com/docs/extensions/reference/userS... ("Availability Pending") [4] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/userScripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

I've edited my comment to also include a link to the Chrome docs, but that FAQ entry also has the link to an issue in the webextensions repository indicating it's a limitation of MV3: https://github.com/w3c/webextensions/issues/112 https://github.com/w3c/webextensions/issues/112

jsnell 3y ago
But that issue has nothing to do with the question of whether the "filter lists" could be updated dynamically without store review. It's asking for a way of programatically triggering the update to the latest version of the extension in the store. That feature request being fixed would do nothing to enable updates without store review. And likewise the feature for doing updates of the ruleset without a store review already exists but is not used by UBOL. So the link doesn't actually support your claim of it being a limitation of MV3. The link is just irrelevant. The FAQ hints at why UBOL doens't make use of that feature, but doesn't actually state it outright.
- bilkow 3y ago
  > So the link doesn't actually support your claim of it being a limitation of MV3. From the issue: "In Manifest V3 remotely hosted code is no longer allowed." Altought the parent was talking specifically about network requests, in which case you may be right and I missed it, but that's not the general problem. Blocking network requests is not sufficient for modern ad/tracking blocking and to be able to run effectively they need to inject scripts into the page, thus "remotely hosted code" is necessary, and the Chrome docs above says that it's not allowed.
  - jsnell 3y ago
    The new complaint in the article was about dynamic updates not being possible. That is just demonstrably incorrect, and not countered in any way by the FAQ link. But you're now trying to switch it to just a relitigation of switching to declarative blocking in general.

gorhill 3y ago

For an extension to be entirely declarative, it must package all the scripts to inject anywhere, the scripting.registerContentScript API doesn't allow injecting code as string[1], the content scripts must be part of the package.[2] There is userScripts API which allows injecting code as string, but it's impractical as in Chromium-based browsers this requires extra steps by the user to enable the API.[3] In Firefox, the documentation for this API has the following note[4]: > When using Manifest V3 or higher, use scripting.registerContentScripts() to register scripts * * * [1] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/scripting/registerContentScripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... [2] https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium/rulesets/scripting https://github.com/uBlockOrigin/uBOL-home/tree/main/chromium... [3] https://developer.chrome.com/docs/extensions/reference/userScripts/#concepts-and-usage https://developer.chrome.com/docs/extensions/reference/userS... ("Availability Pending") [4] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/userScripts https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...