404678 - New security restrictions on file:/// break JsUnit, TIBCO General Interface, etc.

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P1)

Description

[Jesse Costello-Good]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.12 (KHTML, like Gecko) Version/3.0.4 Safari/523.12
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

New security restrictions introduced in Firefox 3 that affect pages loaded from the file:/// domain break existing JavaScript/AJAX applications. I can't find any documentation on this so I'm not sure whether it is a feature or a bug. 

Example 1: Loading a standard instance of JsUnit over file:/// causes all sorts of messages in the error log of the form "Error: uncaught exception: Permission denied to get property Window.xbDEBUG". Loading the same page over http:// shows no errors.

Example 2: Loading any XML document from a relative URI that begins with "file:", "/" or "../" throws a security error with the message "Permission denied to call method XMLDocument.load". Using XMLHttpRequest or the same code in a page loaded from http:// does not raise an error.



Reproducible: Always

Steps to Reproduce:
1. Download JsUnit 2.1 
2. Load testRunner.html into Firefox 3 with a file:/// URI
3. Open Error Console and see messages



I've tested this on Mac OS X 10.4 and Windows XP.

Comment 1

[Jesse Costello-Good]

Download JsUnit 2.1 here: http://internap.dl.sourceforge.net/sourceforge/jsunit/jsunit2_1.zip

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

-> DOM.

I think there is a dupe of this somewhere?

Comment 3

[:Gavin Sharp [email: [e-mail]]]

These were added in bug 230606. I'm not sure there's really anything to be done about this issue without reintroducing the security problems.

Comment 4

[Jesse Costello-Good]

It seems like some balance could be struck given that this change causes Firefox to stop performing like the other major browsers (IE, Safari). 

1. I'm not really sure why JsUnit has to break since JsUnit only relies on accessing JavaScript objects defined by other frames to exist in the global namespace "top". (BTW, JsUnit is pretty popular, is used in Selenium, another popular package, and unfortunately doesn't seem to be under active development.)
2. It looks like you can still use XMLHttpRequest with UniversalRead to get to files above the page (../) but XMLDocument.load does not work even with UniversalRead/UniversalXPConnect. If XMLHttpRequest is not considered a security vulnerability why should XMLDocument be?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> but XMLDocument.load does not work even with UniversalRead/UniversalXPConnect.

That would be a bug.  Either that, or the XMLHttpRequest thing is, as you say.  Confirming based on that, and nominating for investigation, at least; inconsistencies in the security model scare me.

Comment 6

[Mike Schroepfer]

+ing per comment 5 to investigate...

Comment 7

[Daniel Veditz [:dveditz] back January 5, 2026]

Why is there an AJAX application running on file:/// uris?

If it's just for local development and testing then developers can easily relax this restriction by setting the pref security.fileuri.origin-policy to 4 ("traditional").

If you're deploying end-user code this way we'll need to know more about what and why to figure out what might be the best approach.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #7)
> Why is there an AJAX application running on file:/// uris?
Why not?
I have an AJAX application on my laptop which reads cpu speed/temperature and
WLAN and battery levels from /proc/*.
IIRC, after bug 230606 I changed security.fileuri.origin-policy, though that
means that bug 230606 isn't fixed when I'm using my normal FF profile.
Probably I could have changed the AJAX application to ask UniversalXPConnect.

Comment 9

[Damon Sicore (:damons)]

Progress on this?

Comment 10

[Johnny Stenback (:jst)]

From Jonas:
Not blocking on this for this release. This is probably WONTFIX even. If we are going to restrict cross-directory access for file-urls the type of things we want to block are the type of things that this bug asks us not to block. I.e. we're blocking these things by design.

Dan, would be great if you could elaborate here.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Given that we're deprecating XMLDocument.load, I do think we should wontfix this.  If we care, we can do a separate bug on making XMLDocument.load pay attention to UniversalSomething.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, we have decided to not allow "cross-origin" loads using document.load. This isn't primarily because we think cross-origin loads are bad, but because it requires us to change origin on an existing Document object, which is hard to implement while guaranteeing no bugs. Requiring the caller to have UniversalXPConnect isn't really going to help with these bugs.

So unfortunately the recommended solution is to use XMLHttpRequest instead.

If someone can point to exactly what code is failing we should be able to tell you what to replace it with.