Closed Bug 1475832 Opened 6 years ago Closed 3 years ago

WebExtension - WebRequest: it should be possible to cancel or redirect data-URL requests


(WebExtensions :: Request Handling, defect, P3)

61 Branch


(Not tracked)



(Reporter: bugzilla, Unassigned)




(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180705213349

Steps to reproduce:

When using browser.webRequest.onBeforeRequest with blocking it should be possible to cancel or redirect data-URLs.

There is even a "FIXME" comment in the webRequest-Code with this issue...

Reproduction scenario:
- install the provided webExtension temporarily
- go to;base64,PGh0bWw+PGJvZHk+PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLm9yZyI+Y2xpY2s8L2E+PC9ib2R5

Actual results:

The browser console shows that the webExtension found a data-URL and tried to redirect it. But the iFrame displays the data-URLs content and not

Expected results:

The data-URL content is shown.
Flags: needinfo?(mixedpuppy)
This doesn't work because synchronous handling of non-http* requests was removed (necessarily).  We'll probably need a larger effort at rewrite of webrequestcontent and possibly various channels/etc. to make this possible.  So while we should do something here, it's potentially a larger project.
Flags: needinfo?(mixedpuppy)
Priority: -- → P5
Priority: P5 → P3

I ran into this issue, struggled with it, and updated the documentation to reflect the current limitations on non-HTTP(S) protocols on the webRequest MDN page.

Is there currently any kind of workaround available to modify the request in any way? I make an extension that blocks NSFW images and right now my working but highly unfortunate alternative is to intercept and scan text/html via regex for base64 image URLs.

Flags: needinfo?(mixedpuppy)

webRequest is tightly bound to http channels, other protocols just don't work the same. The only alternative I can think of off the top of my head is to use a content script to detect images using data urls.

Flags: needinfo?(mixedpuppy)

I was just doing a bit of backlog management today and remembered this issue, so figured I would link it here. Tracking this bug in my project due to this limitation:

Depends on: 1631933

Should this bug be closed?
Because the feature to observe data urls has been removed in

Flags: needinfo?(rob)

I'll wait until bug 1631933 reached the release channel. If there is zero interest in data:-URLs, then we can close this bug.

Otherwise we can convert this to an open feature request.

Flags: needinfo?(rob)

There is interest in data-URLs. I have to use CSP headers in CanvasBlocker to prevent fingerprinting over these ( which causes several other problems (e.g. directly blocking would be much better.

Better for this issue would be if would be fixed though...

(In reply to kkapsner from comment #7)

Better for this issue would be if would be fixed though...

Definitely... The network level (data:-URLs) is not the right place for your use case. Extensions should be able to run content script in any web page that extensions can load. That's not just data:, but also blob: and sandboxed origins. It's a pet peeve of mine but I haven't got to fix it yet.

Closing bug since data:-URLs are not supported, and there hasn't been a compelling reason to support it again (in particular hardly anyone noticed that the feature disappeared). I've removed the notice from the webRequest docs at

Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.