332572 - Plug-in design: NPN_GetURL doesn't open local files (file://) when the plug-in is on a remote (http://) page

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Olivier Guillion]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

When a plug-in needs to view a local URL (file://) through the NPN_GetURL function, this only works if the plug-in is located in a local page (file:// URL).
When the plug-in is embedded in a remote page (http://) the function returns 1 and no window is open.

This behaviour occurs whatever the target (_blank, _top, _self...) is.
All protocols other than file:// seems to work though.

Reproducible: Always

Steps to Reproduce:
1. Create a test.html page at root level on your C: hard disk
2. Modify one of your existing plug-in to make it call NPN_GetURL("file://C:/test.html","_new") when clicking.
Note: Also tested with 2 or 3 slashes after "file:", with slash or backslash after "C:"
3. Load an page on an http server that embeds your plug-in
4. Click to call the function
Actual Results:  
Nothing happens, (NPN_GetURL returns 1)

Expected Results:  
A new browser window should open, showing the test.html page.

In 3., if you try from a local page that embeds your plug-in, all works as expected.

Comment 1

[Karsten]

I'm facing the same problem with Firefox 2.0.0.3. 

Comment 2

[Karsten]

Additional information:

On the javascript console I get the following error:

Security Error: Content at http://localhost/... may not load or link to file:///c:/test.html.

I thought browser components (like extensions or plugins) are allowed to access local files, but in this case it isn't. So is this a bug or a security feature?

Comment 3

[William Bardwell]

Yeah I see this problem as well.  It is presumably on purpose as a supposed security feature, since HTML pages have similar restrictions imposed on them.
I can see how it could be a security problem to allow browsing to local file urls, but other browsers (e.g. Safari) do not impose this restriction, so maybe this should be relaxed, which might require other fixes.  (E.g. to stop the information leak about what file: urls exist, make all browses to a file: url load a new page, just make the contents of that page be either an error or the proper content.)

Alternately provide a new API like NPN_PushPopupsEnabledState() that lets plug-ins bypass this 'feature'.

Comment 4

[aravindm]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4
Please update if you are able to still reproduce with the latest nightly build  ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/

Comment 5

[William Bardwell]

This still happens with 3.7a5pre (rv:1.9.3a5pre) Gecko/20100420 Minfield/3.7a5pre
It is a design choice, so that is presumably why it hasn't been fixed.  Requesting reproductions when there is no chance that someone has fixed it is bogus.

Comment 6

[Olivier Guillion]

If it's by design, I can't see the point.
A plug-in can call system functions to read or write files anyway, so why calling NPN_GetURL, i.e. showing the content of a local file in a browser's window could be more harmful than that?

Since 2006, I could work around the problem, but a final explanation about the reasons of this limitations would save time, close this bug report and save HD space on bugzilla :)

Comment 7

[William Bardwell]

Well I would assume that it is fall-out from adding that limitation to HTML links.  I don't think that it is a great idea, but I dunno.  I was assuming that it was on purpose, but that something to disable it selectively should be added similar to how pop-up suppression can be disabled.