Created attachment 8839529 [details] 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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1256122
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: Redirect to extension page fails if no access to file URLs is granted → WebRequest API does not support file: requests
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"]`
(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.
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
file system investigate
+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.
(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.
See Also: → bug 1457500
You need to log in before you can comment on or make changes to this bug.