1341341 - WebRequest API does not support file: requests

Status: NEW

(WebExtensions :: Request Handling, defect, P3)

Description

[testit]

Attachment: testit.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

My extensions registers as a listener to webRequest.onBeforeRequest. This is done to redirect the user to my extension main page if he opens a local epub file.

Here are the steps to reproduce the problem:

- Download and unzip the attached test case. Load the extension via "about:debugging". 

- Open the file explorer and open the file "testit.epub" (included in the zip file) via right click and by selecting "Firefox".

- The standard file save dialog is displayed.

As my extension registered as a listener to webRequest.onBeforeRequest with a filter to all file URLs with the extension ".epub", the request should be redirected to the main page of my extension. The file url should be passed as a parameter.

The reason this didn't happen is, that access to file URLs was not granted to my extension. Currently exists no user interface to grant access to file URLs.

So in general this is not a bug because the extension behaves as expected. I created this bug to show a use case for granting access to file URLs.

Comment 2

[testit]

This is not a duplicate of bug 1256122. 

The redirect in 1256122 fails because it's not allowed to redirect a http:// url to an extension page. An error message is logged.

The redirect in this bug fails, because no access to file URLs is granted. The webRequest.onBeforeRequest listener is not called at all. No error message is logged.

Comment 3

[Memmie Lenglet]

I think the problem come from the `browser.webRequest.onBeforeRequest.addListener`'s filter `"urls": ["file://*/*.epub", "file://*/*.EPUB"]`.
The syntax is invalid according to https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Match_patterns#Invalid_match_patterns
Should be `"urls": ["file:///*.epub", "file:///*.EPUB"]`

Comment 4

[testit]

(In reply to Memmie Lenglet from comment #3)
> I think the problem come from the
> `browser.webRequest.onBeforeRequest.addListener`'s filter `"urls":
> ["file://*/*.epub", "file://*/*.EPUB"]`.
> The syntax is invalid according to
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/
> Match_patterns#Invalid_match_patterns
> Should be `"urls": ["file:///*.epub", "file:///*.EPUB"]`

I tried it with the changes you suggested. Unfortunately, this doesn't make a difference, it still doesn't work.

Comment 5

[Memmie Lenglet]

Ok I found the why. In fact the docs says:
"Only requests made using HTTP or HTTPS will trigger events, even though match patterns can match some other protocols"
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/RequestFilter

An API like registerContentHandler should be used, but it's seem impossible to use with WebExtensions:
"For security reasons, it's not possible for an extension or web site to register content handlers targeting other sites"
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerContentHandler

Comment 6

[:shell escalante]

file system investigate

Comment 7

[eight04]

+1. I would like to create an extension that can view .ans files in the browser. However, when dragging the file into the browser, Firefox sometimes downloads the file instead of displaying it as plain text, hence the extension has no chance to parse/display them.

Comment 8

[Rob Wu [:robwu]]

(In reply to eight04 from comment #7)
> +1. I would like to create an extension that can view .ans files in the
> browser. However, when dragging the file into the browser, Firefox sometimes
> downloads the file instead of displaying it as plain text, hence the
> extension has no chance to parse/display them.

If bug 1457500 is implemented via the webRequest API, then this bug blocks bug 1457500.
Otherwise (if a new API is introduced), your use case would be addressed by bug 1457500.

Comment 9

[lanzkron]

(In reply to Memmie Lenglet from comment #5)

Ok I found the why. In fact the docs says:
"Only requests made using HTTP or HTTPS will trigger events, even though
match patterns can match some other protocols"
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/
RequestFilter

An API like registerContentHandler should be used, but it's seem impossible
to use with WebExtensions:
"For security reasons, it's not possible for an extension or web site to
register content handlers targeting other sites"
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/
registerContentHandler

Any idea why this limitation is in place? As the docs say this feature is based on Chrome's webRequest API which does support file:/// scheme URLs.

Comment 10

[wingman.jr.addon]

I suspect it is more of an implementation detail in part. From this bug around data URL's I went staring at the source code a bit and I think there is just not a single abstraction at the appropriate level for all data streams that come in as URLs, so it requires special handling.
I also tried changing the filter to <ALL_URLS> because that can - contrary to the documentation - trigger the onBeforeRequest event for data: URL's. No luck here however.