1421102 - Allow tabs.update to open file:/// URLs

Status: RESOLVED DUPLICATE of bug 1246236

(WebExtensions :: General, defect)

Description

[Ben Basson]

A supported Firefox behaviour is to set your homepage to a local file, e.g. file:///path/to/some.html

After resolutions to bug 1322308 and bug 1234150, I can read the homepage and direct new tabs to load that homepage, e.g using tabs.update({url: homepage})

However, loading a file:/// URI appears to be specifically disallowed for some reason.

> Unchecked lastError value: Error: Illegal URL: file:///D:/path/to/test/test.html
> ExtensionCommon.jsm:407

Notes:

1) If you press the Home button, the page is loaded as expected
2) If you middle click the Home button, the new tab loads the page as expected
3) If the homepage is set to "D:\path\to\test\test.html" (e.g. normal Windows path, without "file:///" and only using backslashes, then the page loads as expected.
4) I have no idea what happens on Linux, but I imagine the workaround above (3) will not work at all.

So the desired behaviour _is possible_ on Windows at least, assuming that you ignore how Firefox sets a homepage, and type in the path yourself.

However, for an addon to support this, there are additional complications. For example, the path has to be urldecoded to deal with spaces (that Firefox writes into %20), slashes have to be rewritten, and there'll probably be additional problems to solve on Linux if it's even possible to make this work at all.

It would be better if the tab API could just support something that the browser UI already supports.

Comment 2

[Ben Basson]

That is not the same bug (my opinion). I do not want to read the local file system, I just want to load a file (from disk) in a tab, just like clicking the Home button does.

This used to work _fine_ using the legacy (now desupported) NewTabURL.jsm to override the homepage.

Can you please reconsider marking as duplicate? This is a tabs API issue, not a general file reading issue (which I assume will likely never be resolved, whereas this at least has a remote chance).

Comment 3

[Ben Basson]

Further more, the thing I want to do is also (more or less) possible on Windows, but poorly supported, and likely not supported for Linux/Mac.

Comment 4

[Kris Maglione [:kmag]]

No, allowing extensions to open file: URLs is inextricably intertwined with allowing them filesystem access.

Comment 5

[Ben Basson]

Like I said, I don't want to *open* the file: URL, I want the tabs API to do that. 

Unless I'm missing something, in this scenario the add-on would have no access to the content of the file.

Comment 6

[Kris Maglione [:kmag]]

You want to use the tabs API to open the file. The add-on would have access to the content of the file, yes. It would be able to inject content scripts into it or use the captureVisibleTab API to take screenshots of it.

Comment 7

[Ben Basson]

Well, if this is a WONTFIX on security grounds then you have a security hole on Windows as described above.

I will let my add-on users know that this will no longer be possible.

Comment 8

[leonardo.rojas]

@kmag, What is the recommended venue to regain this functionality?

To recap:

The use case for an extension to access a local file is to enable the user to see their home page in a new tab.

Setting the the home-page to a local file is already exposed in `about:preferences`.

An extension is needed because firefox does not offer the option to open the user's home-page in a new tab anymore.

An example of an extension that provides the missing functionality is https://addons.mozilla.org/en-US/firefox/addon/new-tab-homepage/

If extensions will not be allowed to access the file system anymore, what needs to be done to bring back this functionality to firefox?

Comment 9

[Ben Basson]

Sorry, I still dispute that this is a duplicate, I am asking for a fundamentally different thing than filesystem access - and I am specifically not asking to read the contents of files. 

I accept that more thought needs to occur than I first imagined (namely, there appears to be weaknesses in the WebExtensions security model that would currently block this from being implemented).

> It would be able to inject content scripts into it or use the captureVisibleTab API to take screenshots of it.

I'm a little bit confused about the mixed messages here. If you read the tabs.executeScript() API page it says:

> You can only inject code into pages whose URL can be expressed using a match pattern: meaning, 
> its scheme must be one of "http", "https", "file", "ftp". This means that you can't inject code 
> into any of the browser's built-in pages, such as about:debugging [...]

That implies that injecting script into file:/// is acceptable, but you're essentially saying nothing should be loaded using file:/// - so how would the former ever be possible given the latter? Is this a documentation mistake?

Either way, if same restriction that exists for about:* pages could be applied to file:/// pages - i.e. do not permit script injection - then this bug would be more viable for later implementation.

Likewise for captureVisibleTab (which oddly appears to have no restrictions listed, but presumably must have some).

Again, this isn't about reading files from disk, this is about Firefox loading and rendering these pages. If there are any other possible ways this could be implemented via WebExtensions (that don't involve any security problems) I'd love to hear them.