Event doesn't fire from XUL file but does when loaded from HTML file

VERIFIED FIXED in mozilla0.9



19 years ago
18 years ago


(Reporter: peter.vanderbeken, Assigned: security-bugs)


Mac System 8.5

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm-])


(5 attachments)



19 years ago
If you put these four files somewhere in your chrome folder, and load the 
test.html file, it works ok. If you load the test.xul file, it doesn't. Use 
chrome:// URLs to load the files. You'll have to edit test.html and test.xul to 
point to the right location for test.js.

Expected result: alert box that says "Test"
Actual result: no alert box when using .xul file

The event is fired (from nsXMLDocument::EndLoad), but is stopped by 
nsScriptSecurityManager in CheckFunctionAccess (returning 
NS_ERROR_DOM_SECURITY_ERR). The difference between the two is when 
using a html file, the test (if (isSameOrigin)) at line 640 of mozilla/
caps/src/nsScriptSecurityManager.cpp succeeds, and for a xul file it fails.

This is currently blocking my work on the chrome for Transformiix (XSLT 

Comment 1

19 years ago
Created attachment 15551 [details]
test.html - works ok

Comment 2

19 years ago
Created attachment 15552 [details]
test.xul - doesn't work ok

Comment 3

19 years ago
Created attachment 15553 [details]

Comment 4

19 years ago
Created attachment 15554 [details]
dup of 53493. I have a patch, waiting on approval. Peter, if you need a quick
fix, apply my patch from 53493. 

*** This bug has been marked as a duplicate of 53493 ***
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 6

19 years ago
Verified dupe.

Comment 7

19 years ago
Hmm, actually, this is not a dupe. Bug 53493 has to do with html files not 
working from inside chrome. I have no problem with the html file, it's when 
using the xul file that it doesn't work. Reopening.
Resolution: DUPLICATE → ---


19 years ago
Depends on: 53493
Nonetheless, this will be fixed by 53493, I think. 
Keywords: nsbeta3, rtm
Target Milestone: --- → M16

Comment 9

19 years ago
Ok, because you're so persistent, I'll try out the patch to 53493.


Comment 10

19 years ago
I tried the patch to 53493 and as I expected, it doesn't fix this bug at all. I 

don't think they are related.

Comment 11

18 years ago
For me, `load' only works when the URL is a simple file name or of 
the file:// syntax, and the load is contained in a HTML file.  I can't
get JavaScript loaded from XUL files to send notifications.  Tracing through
nsXMLDocument::Load, it looks like it passes the security checks..

Comment 12

18 years ago
rtm-, I don't see that any existing xul is impacted by this bug.  Getting a fix
into the trunk for Transformiix is a good thing though.
Whiteboard: [rtm-]


18 years ago
QA Contact: czhang → junruh

Comment 13

18 years ago
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer

Comment 14

18 years ago
I was overjoyed to encounter this bug today.  Here's what I found is and is not 

I CAN load a file from a file:// html document.
I CAN NOT load a file from a chrome:// html document.
I CAN load a file from a file:// xul document.
I CAN NOT load a file from a chrome:// xul document.

So, in other words, regardless of the document type, xml loading through script 
fails when your app document is loaded through chrome://

Comment 15

18 years ago
I've traced the problem down a little further.  As Peter stated in the bug 
report, the Equals at line 640 in nsScriptSecurityManager is failing when the 
source document comes from chrome.  This is because the two principals being 
compared in this case are a SystemPrincipal and an AggregatePrincipal.  The 
SystemPrincipal comes from the function that was declared in the chrome 
document.  The AggregatePrincipal comes from the document object that is the 
target of the "load" event, and it contains a CodebasePrincipal that points to 
the xml document you have loaded. 

It looks to me that the security manager is rejecting this event handler 
because it assumes the CodebasePrincipal is some evil web document that is 
trying to intercept events from the SystemPrincipal.  In this case, this is 
obviously not so.  What needs to happen is that when an xml document is created 
for data purposes only, it's js object should have the same principal as the 
context where it was created.  Since this document will never be presented, and 
therefore, never be able to do evil things to the user, it should not need to 
have an AggregatePrincipal all the time.

CC'ing the XML DOM guys since this is getting into their domain.

  Could you post a testcase for the situation you described (the one that doesn't 

Comment 17

18 years ago
Mitch, i think you can use the existing testcases to try it out. Put them
somewhere in the chrome directory and try to load test.xul with a chrome URL.
Now that Joe seems to have found what the problem is, any chance we could get a
fix? If you don't have time for this, could you see if Joe's solution is correct
and show us where to implement it?


18 years ago
Target Milestone: M16 → ---
Mass adding mozilla0.9 keyword (mass changing milestone doesn't seem to work).
Keywords: mozilla0.9
Setting milestone to Moz0.9.
Target Milestone: --- → mozilla0.9
Created attachment 28531 [details] [diff] [review]
Here's a fix for chrome accessing chrome and chrome accessing non-chrome.
Two parts to the above patch. The nsXMLDocument part gets the new document's
principal from the channel that loaded it if the channel provided a principal.
This is the same behavior as a normal document load in a browser window. This
way, if the channel assigns the system principal (as a chrome load will do), the
generated XML document will be given the system principal.

The other part is to add a check for system principal to
nsScriptSecurityManager::CheckFunctionAccess. This is the security check
function called when avent handlers are about to be run. THe system principal
should be able to capture events from any domain.

Comment 22

18 years ago
I can't say security is my strong field, but it looks ok to me, r=heikki.
Fix checked in.
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED

Comment 25

18 years ago
It works now, thanks Mitchell. Marking verified.
You need to log in before you can comment on or make changes to this bug.