Basic idea: 1. Define an iframe in xul 2. document.write() content into the iframe 3. Retrieve a reference to a DOM element inside the iframe. 3a. NS_ERROR_DOM_SECURITY_ERR is thrown. Test Case: 1. Place the three attached files in the path resource:/// points to 2. load rg-tests-index.html 3. Click 'dom security' 3a. Error will be generated.
I've reproduced the problem. Security is objecting to getting "getElementById" from about:blank from a script running from file: (the resource: is converted to file:). I think the problem is that writing to the document should change its origin from about:blank to the origin of the script performing the write. I'll investigate more.
Checking in nsHTMLDocument.cpp; /m/pub/mozilla/layout/html/document/src/nsHTMLDocument.cpp,v <-- nsHTMLDocumen t.cpp new revision: 3.162; previous revision: 3.161 done This fixes Bugzilla bug 16836 where a XUL document creates a new window and tries to document.write to it. It was getting a security error because the call to GetSourceDocumentURL failed, causing the new window's document's URI to be set to about:blank, which failed an origin check relative to the origin of the script. The call to GetSourceDocumentURL failed because the document was a XUL document rather than an HTML document. The proposed change uses the more general nsIDocument interface to get the uri (and avoids creating a new object for the uri).
Bulk moving all Browser Security bugs to new Security: General component. The previous Security component for Browser will be deleted.