...
>After discussing this with several content blocking extension developers, we have decided to implement DNR and continue maintaining support for blocking webRequest.
We've seen this before -- a number of times. This is what's put forth to avoid a cacophony and push back from developers and end-users alike. Both technologies will be supported for a short time before blocking webRequest is taken out altogether at a relatively short time thereafter.
>We will support blocking webRequest until there’s a better solution which covers all use cases we consider important ... (emphasis mine)
And there it is.
In a short time we'll read a statement -- released on a Friday afternoon -- stating the EOL for blocking webRequest with little-to-nothing in the way of analogous behavior because it wasn't considered important by Mozilla (or, perhaps, the pressure from Google was too much).
That's my cynical, entirely pessimistic outlook of it all anyway.
I'd like to read Raymond Hill's thoughts on this.
However, if Mozilla intended to keep the option of blocking webRequest (or whatever's necessary to keep uBlock possible), it would also look like this. It's not an option for Mozilla not to support the Chrome API, because the entire point of WebExtensions is the admission that Chrome is the dominant browser, and extension makers will only consider porting to Firefox if it's as little effort as possible. Hence they need to support the same API's.
Given that uBlock Origin was the first extension they added support for in Firefox for Android, I'm relatively confident that they're intent on making sure it stays able to do its job.
At least the last time I developed a browser extension, this was not the case. I found that what was considered the WebExtension API was not 100% portable across browsers, and I had to rewrite parts of my code between Chrome and Firefox because Chrome had many extra APIs that Firefox lacked.