[ffsm8]

They could, theoretically. But just imagine what that actually means. Unless you cease merging upstream/the project you've forked, you'll have to resolve all conflicts caused by this divergence.

And that's a lot of work for a multi million LOC project, unless the architecture is specifically made to support such extensions... which isn't the case here.

And freezing your merges indefinitely isn't really viable either for a browser

[Zak]

A quick look at the code gives me the impression that webRequestBlocking is a fairly trivial modification to webRequest, and they seem to be keeping the latter. This leads me to two conclusions: it wouldn't be terribly hard for a fork maintainer to keep webRequestBlocking, and Google's technical excuses for removing it are disingenuous.

[justinclift]

> ... and Google's technical excuses for removing it are disingenuous.

That's been the default assumption of pretty much everyone anyway.

[account42]

That may be true now but will it still be true when Google next refactors their request code under the assumption that no requirements for a webRequestBlocking API exist.

[SirMaster]

So go make an LLM manage the fork or something. Everyone keeps telling me they are amazing at code these days. Surely it can do a task like that if that's all it's doing all day.

If not today maybe soon...