364613 - file:// URLs unable to link to/load other file:// resources

Status: NEW

(Thunderbird :: General, defect)

Description

[Massimiliano Mirra]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

According to http://kb.mozillazine.org/Links_to_local_pages_don't_work, links from remote content to file:// URLs will not work.

However, it seems that this restriction also extends to content loaded from a file:// URL that links other file:// resources. Not only a local page is not able to link to other local pages, it cannot even load local scripts and style sheets.

In other words, the following seems not to have any effect when contained in a local document:


  <a href="file://..."> (absolute)
  <a href="..."> (relative)
  <script src="file://...">
  <script src="...">
  <link href="file://...">
  <link href="..."> 

Loading remote (http://) works fine instead.



Reproducible: Always

Steps to Reproduce:
1. Unpack attached test case in /tmp.
2. Open the JavaScript console.
3. Type (on a single line, here broken in two for readability):

  main = Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getEnumerator('').getNext();
  main.getMessageBrowser().loadURI('file:///tmp/test.html');


Actual Results:  
On 2.0b1, page is not loaded at all.  On 1.5, page is loaded and shown, but style sheet is not applied, scripts are not loaded, link to other local file is not followed.

Expected Results:  
Style sheet and scripts should be loaded and applied/evaluated.

I am helping with porting xmpp4moz (http://dev.hyperstruct.net/xmpp4moz), a Jabber/XMPP layer, and SamePlace (http://dev.hyperstruct.net/xmpp4moz/wiki/LocalApplicationSamePlace), an IM client, to Thunderbird. Chats are HTML documents and they load a local style sheet and several local scripts; they work fine in Firefox, while the above issue blocks them from working in Thunderbird.

I tried to adapt instructions from http://kb.mozillazine.org/Links_to_local_pages_don't_work to enable access of file:// URLs from file:// content, without success:

user_pref ("capability.policy.policynames", "localfilelinks");
user_pref ("capability.policy.localfilelinks.sites","file://");
user_pref ("capability.policy.localfilelinks.sites","file:");
user_pref ("capability.policy.localfilelinks.sites","file://localhost");
user_pref ("capability.policy.localfilelinks.sites","file:///tmp/test.html");
user_pref ("capability.policy.localfilelinks.sites","file://localhost/tmp/test.html");
user_pref ("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

Comment 1

[Massimiliano Mirra]

Attachment: testcase

Comment 2

[Magnus Melin [:mkmelin]]

I don't know how that should be done, but I don't think its a good way for the application/extension(?) to do it by enabling that policy pref...

Comment 3

[Massimiliano Mirra]

(In reply to comment #2)
> I don't know how that should be done, but I don't think its a good way for the
> application/extension(?) to do it by enabling that policy pref...

Would you mind expanding a bit on why?  I am not too fond of it either, however the issue seems to be precisely one of policy and the above lines should bring policy on par with the one used in Firefox, if I am not mistaken.  (They do not work anyway, so this is kind of a moot point.)

Comment 4

[Magnus Melin [:mkmelin]]

By enabling free access to file:, it's easy for someone to read your files, and send the data to their server... 

Comment 5

[Massimiliano Mirra]

(In reply to comment #4)
> By enabling free access to file:, it's easy for someone to read your files, and
> send the data to their server... 

Indeed.  If I understand correctly, however, those policy lines do not allow "free" access to file:// resources, they only allow access from other file:// resources.

Comment 6

[Magnus Melin [:mkmelin]]

I don't think so, those policy prefs are for remote content and making it possible for trusted such to access file: resources. File resources already have access to other file resources.

Comment 7

[Massimiliano Mirra]

(In reply to comment #6)
> I don't think so, those policy prefs are for remote content and making it
> possible for trusted such to access file: resources.

http://www.mozilla.org/projects/security/components/ConfigPolicy.html
says:

    The sites line has this format:
    user_pref("capability.policy.<policy name>.sites","<URL list>");

...where the third parameter is the URLs one is setting a policy for.

In this case, I am trying to set an "allAccess" policy for "file://",
"file:", "file://localhost", "file:///tmp/test.html", and
"file://localhost/tmp/test.html", not for remote sites.

You mention that policy preferences are fore remote content, which
would explain why setting it for local content does not work.

(Again, I am not an expert on the subject and I might be reading the
ConfigPolicy.html document incorrectly.)

> File resources already have access to other file resources.

I would be most grateful for a test case showing this, as from the
experiments I have done (see also attached test case) this does not
seem to work.

Comment 8

[Magnus Melin [:mkmelin]]

(In reply to comment #7)
> I would be most grateful for a test case showing this, as from the
> experiments I have done (see also attached test case) this does not
> seem to work.

A simple test case would be to create an html file containg <img src="file:///path/to/file.jpg" />

This will work fine when you open the file locally, but when put on a server, it won't load unless you set the policy to allow it for the site. 

Comment 9

[Massimiliano Mirra]

(In reply to comment #8)
> A simple test case would be to create an html file containg <img
> src="file:///path/to/file.jpg" />
> 
> This will work fine when you open the file locally, but when put on a server,
> it won't load unless you set the policy to allow it for the site. 

Thanks again for your help.  How are you opening the file?  I am using
getMessageBrowser().loadURI('file:///tmp/test.html'): 1.5 loads the
file but does not show the image, 2.0a1 does not load anything.

Comment 10

[Magnus Melin [:mkmelin]]

I meant just to open that simple html file in the browser (writing in the url, choosing open file or whatever)... Don't know much how it should be done programatically. Policy wise it shouldn't matter.

You may also want to upgrade from 2.0a1 to a recent nightly, just so you aren't hitting some bug that has been fixed already.

Comment 11

[Massimiliano Mirra]

(In reply to comment #10)
> I meant just to open that simple html file in the browser (writing in the url,
> choosing open file or whatever)... 

I don't see a way of writing in the url or opening a local file in Thunderbird.

> Don't know much how it should be done
> programatically. Policy wise it shouldn't matter.

An example that can be run from the JavaScript console is provided in the first message of this report under "Steps to Reproduce".  If you have a moment, please try it so if you get the same behaviour this bug can be confirmed.

> You may also want to upgrade from 2.0a1 to a recent nightly, just so you aren't
> hitting some bug that has been fixed already.

Yes.  Tried with nightly 28/12, the problem is still here.

Comment 12

[Magnus Melin [:mkmelin]]

> I don't see a way of writing in the url or opening a local file in Thunderbird.

Well, you can always use the mail start page, found in the preferences :)

So, i tried 
var x = Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getEnumerator('').getNext(); x.getMessageBrowser().loadURI('file:///home/magnus/tmp/test.1/file.html');

It loads the page itself, but the picture in it is not shown. If the file to load is an image file, the pic shows. 

Doesn't seem bug 360814 affected this, I tried it with a build before that regression, but it's worth keeping in mind if you are trying to find out what's wrong.

Comment 13

[Massimiliano Mirra]

(In reply to comment #12)
> Doesn't seem bug 360814 affected this, I tried it with a build before that
> regression, but it's worth keeping in mind if you are trying to find out what's
> wrong.

Thanks for the test and for pointer, Magnus.  I am taking a stab at this, or rather at its more evil brother in 2.0b1 (I have next to zero knowledge of TB internals and little hope that I will hit the target, but still).  There seems to be good reason now to mark this as NEW, someone with appropriate permissions could please do it?

Also leaving priority to normal, as I think only SamePlace/XMPP4Moz are blocked by it, but if anybody else believes that having GMail-style IM integration in TB is a Good Thing, consider increasing it to major. :-)

Comment 14

[Magnus Melin [:mkmelin]]

->NEW 

I'm not 100% sure this is a bug per se (certainly not a new one), but it seems reasonable it should work.