> Isn't this basically the same concept they already used with ordinary content scripts for years?
It was implicit, now it's explicit and it gives more control and better understanding. It also allows introducing more levels of isolation, like a separate "USER_SCRIPTS" world or "MAIN", before that you had to mess with evals and adding script tags.
> Yes, but those too are just an improvement compared to the previous state of MV3
Yes, that's why I listed these as improvements.
> And it again sounds like "we're now slightly less shitty to extension devs than we were before".
They went from "1 person that tries to make things not crumble" to a large team of developers, it's a big step forward. What signal do we send them if we always say "everything you're doing is bad" even when it's factually not true?
> Firefox shows that it's no technical problem at all to implement both APIs at the same time.
At first we all thought that DNR is there for them to limit content blockers. With time they proved us wrong when they worked hard on improving it and covering more and more use cases.
Now I tend to think that this is an engineering decision that's driven by the other change - the shift from persistent background pages to service workers.
Is there a better solution that could save the blocking webRequest and achieving their goals at the same time? Most likely there is, but how hard would it be to implement it instead or what if it requires an architectural change? Anyways, these are speculations, I am with you here and I don't support blocking webRequest removal.
