Extensions can not load file: URLs
Categories
(WebExtensions :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: dw-dev, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [UX needed possibly] triaged )
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Updated•9 years ago
|
Comment 1•9 years ago
|
||
Comment 3•9 years ago
|
||
Updated•8 years ago
|
Comment 9•8 years ago
|
||
Comment 10•8 years ago
|
||
Comment 11•8 years ago
|
||
Comment 12•8 years ago
|
||
Comment 14•8 years ago
|
||
Comment 15•8 years ago
|
||
Comment 16•8 years ago
|
||
Updated•8 years ago
|
Updated•8 years ago
|
Comment 17•7 years ago
|
||
Comment 18•7 years ago
|
||
Comment 19•7 years ago
|
||
Comment 20•7 years ago
|
||
Comment 21•7 years ago
|
||
Comment 22•7 years ago
|
||
Comment 23•7 years ago
|
||
Comment 26•7 years ago
|
||
Comment 27•7 years ago
|
||
Comment 28•7 years ago
|
||
Comment 29•7 years ago
|
||
Comment 30•7 years ago
|
||
Comment 31•7 years ago
|
||
Comment 32•7 years ago
|
||
Comment 33•7 years ago
|
||
Comment 34•7 years ago
|
||
Comment 35•7 years ago
|
||
Comment 36•7 years ago
|
||
Updated•6 years ago
|
Comment 37•6 years ago
|
||
Comment 40•6 years ago
|
||
Comment 41•6 years ago
|
||
It seems that Chrome now adds the incognito-mode checkbox to all extensions, and the file URLs checkbox to anything that asks for '<all_urls>' or anything starting with 'file://'. At least, that's the impression I get from the documentation at https://developer.chrome.com/extensions/permission_warnings.
Apparently they also have methods to check these settings at extension.isAllowedFileSchemeAccess() and extension.isAllowedIncognitoAccess(), presumably so that extensions can alert users that certain things won't work, for example, if it's a request blocker intended to improve privacy.
Actually, MDN claims Firefox implements both methods already:
(It does not, however, state that Firefox's implementation of either one does anything more complicated than returning a hard-coded value.)
Comment 42•6 years ago
|
||
(In reply to Samuel Bronson from comment #41)
Unrelated to file access, but available starting with 67.
Comment 43•5 years ago
|
||
Refreshing patch for 68ESR.
Comment 44•4 years ago
|
||
I have a suggestion.
Let WebExtension not be able to read the contents of the tab "file: // *", let it not be possible to check the status like "no file", "loading", "tab loaded" etc.
But let it be able to open "file: // *" at all without waiting for any permissions.
Now in Firefox you can not even assign such permissions, and I think they are even unnecessary. I believe it is possible to be able to open a tab with "file: // *" without permission by simply blocking the reading of any data about that tab, except that it is just in the list of tabs.
Comment hidden (me-too) |
I don't see why the type of scheme is important anyway: surely any valid URI should be accepted, whether it be file:, ftp:, http:, https:, webdav:, or about:?
Updated•2 years ago
|
Comment 47•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates, 40 votes and 66 CCs.
:robwu, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 48•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Updated•2 years ago
|
Comment 49•2 years ago
|
||
Clearing the needinfo request I requested six years ago.
Description
•