3 ms·
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 co
by ffsm8 2y ago
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 2y agoA 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 2y ago> ... and Google's technical excuses for removing it are disingenuous. That's been the default assumption of pretty much everyone anyway.
- account42 2y agoThat 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 2y agoSo 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...