Bugzilla

The support for `data:`-URIs in the webRequest is very limited: `webRequest.onBeforeRequest` (and `webRequest.onCompleted`) are the only supported events, and only in an observational capacity (i.e. it is not possible to block data:-URL requests).

Despite that, there is a significant amount of code to support this, in [WebRequestContent.js](https://searchfox.org/mozilla-central/rev/3446310d6cc5c85cde16a82eccf560e9b71a3d44/toolkit/components/extensions/webrequest/WebRequestContent.js) and elsewhere. The code has bugs, e.g. with Fission enabled `data:`-requests are not propagated from cross-origin frames.

Originally `WebRequestContent.js` was used as the backend for webRequest events. These days, it is not relevant any more:
- http(s) and ws(s) are handled in the parent (as of bug 1163862)
- file:-URLs are not supported (bug 1341341). Even if it were, it would better be handled in the parent process.
- data:-URL support is very limited (this bug, and note that Chromium doesn't support it).
- ftp: is not supported and is not going to be (bug 1312460).

Given the very limited use of data:-URLs, I propose to drop support for `data:`-URLs in the webRequest API, to enable us to clean up some code and fix (perf) bugs.

The support for `data:`-URIs in the webRequest is very limited: `webRequest.onBeforeRequest` (and `webRequest.onCompleted`) are the only supported events, and only in an observational capacity (i.e. it is not possible to block data:-URL requests, which means that the API has little value for content blockers, such as NoScript and uBlock; I checked their sources and didn't see any special handling for it).

Despite that, there is a significant amount of code to support this, in [WebRequestContent.js](https://searchfox.org/mozilla-central/rev/3446310d6cc5c85cde16a82eccf560e9b71a3d44/toolkit/components/extensions/webrequest/WebRequestContent.js) and elsewhere. The code has bugs, e.g. with Fission enabled `data:`-requests are not propagated from cross-origin frames.

Originally `WebRequestContent.js` was used as the backend for webRequest events. These days, it is not relevant any more:
- http(s) and ws(s) are handled in the parent (as of bug 1163862)
- file:-URLs are not supported (bug 1341341). Even if it were, it would better be handled in the parent process.
- data:-URL support is very limited (this bug, and note that Chromium doesn't support it).
- ftp: is not supported and is not going to be (bug 1312460).

Given the very limited use of data:-URLs, I propose to drop support for `data:`-URLs in the webRequest API, to enable us to clean up some code and fix (perf) bugs.