uBlock Origin does not intercept anything

[powellnorma]

Describe the bug

I tried both:
https://chromewebstore.google.com/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm?hl=en
https://chromewebstore.google.com/detail/ublock-origin-lite/ddkjiahejlhfcafbddmgiahcphecmpfh?hl=en

But they fail to intercept anything, can be tested e.g. with:
https://blockads.fivefilters.org/

Additional context

I think this is caused by using session.webRequest.onBeforeSendHeaders, since it works fine in https://github.com/samuelmaddock/electron-browser-shell before adding such hooks for #45. Is there something we can do, or is this an electron bug?

[powellnorma]

I see this limitation is also mentioned in electron-browser-shell's electron-chrome-extensions/README.md.

Maybe it would be worth to work around this by moving all "request interception" stuff into web-extensions. For example, adjusting the user agent (#45) should be doable in a web extension as well, right?

[iamEvanYT]

This is a known issue. Your solution sounds cool but I was looking at a different solution, such as intercepting all these webRequest calls and routing them to the main process.

[powellnorma]

That could work as well. However, I wonder

• if there is a performance impact, since, depending on what the extension is doing, we'd need to IPC (potentially) a lot of data. I wonder how the current implementation from electron handles this. Even if it also copies from one process to another, it might have done some optimizations for this in C++. I believe here is some code related to offering the chrome.webRequest extension API: https://github.com/electron/electron/blob/fa844268eccaf5d54e11652eea35e685482703a1/shell/browser/net/proxying_url_loader_factory.h#L49 (it might offer a starting point for further "investigation" (looking at how electron does this)).
• How much reimplementation is needed, of things which currently the built-in chrome.webRequest (from electron) is handling. Maybe the abstractions from betterWebRequest are already (mostly) enough, maybe not.

OTOH, if we were able to move current "request interception stuff" into web-extensions, we could reuse more logic electron is already providing.

That is just my view, those points I mentioned might not be an issue at all, just sharing my thoughts.

Are there things which need (e.g.) webRequest.onBeforeSendHeaders in the main process, that would not work (easily) if done as WebExtension? I guess if electron decides to drop MV2 support, MV3 might not be enough for some things?

Edit:
Did a bit of research…
https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline
Chrome 138 is the final version of Chrome to support Manifest V2 extensions

That means, starting with electron 38, MV2 Support will be gone:
https://www.electronjs.org/docs/latest/tutorial/electron-timelines

EOL for electron 37 is 2026-Jan-13.

MV3 compared to MV2 has some significant downsides apparently..

• can't change rules after extension was loaded
• Many rules can't be translated into a MV3 equivalent, becuase MV3's declarativeNetRequest is not as expressive: uBlockOrigin/uBlock-issues#338 (comment)

So I think your approach is better long-term