Last Comment Bug 310650 - XMLPrettyPrint broken, Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR
: XMLPrettyPrint broken, Exception... "Security error" code: "1000" nsresult: ...
Status: RESOLVED FIXED
: fixed1.8, regression
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Peter Van der Beken [:peterv]
:
Mentors:
data:application/xml;charset=utf-8;ba...
Depends on:
Blocks: 278472
  Show dependency treegraph
 
Reported: 2005-09-30 23:04 PDT by Jonathan Stanley
Modified: 2008-07-31 02:43 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 (879 bytes, patch)
2005-10-01 09:07 PDT, Peter Van der Beken [:peterv]
bzbarsky: review+
bzbarsky: superreview+
shaver: approval1.8b5+
Details | Diff | Review

Description Jonathan Stanley 2005-09-30 23:04:36 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050930 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050930 SeaMonkey/1.1a

The above page should display the following XML tree:

<root>
<foo>Blah</foo>
<bar/>
</root>

However, in the current tinder-box builds of Firefox, it just returns a blank page.

Tested with the following builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050930
Firefox/1.6a1 ID:2005093003 - Pass
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050930
Firefox/1.6a1 ID:2005093018 - Fail
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050930
Firefox/1.6a1 ID:2005093021 - Fail

So it broke sometime between 03:00 30th Sep. and 18:00 30th Sep.:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=day&mindate=&maxdate=&cvsroot=%2Fcvsroot

The error console shows:

Error: [Exception... "Security error"  code: "1000" nsresult: "0x805303e8
(NS_ERROR_DOM_SECURITY_ERR)"  location:
"chrome://global/content/xml/XMLPrettyPrint.xml Line: 55"]
Source file: chrome://global/content/xml/XMLPrettyPrint.xml
Line: 55


Reproducible: Always

Steps to Reproduce:
1. Visit above link
2. Should show XML tree (as unstyled XML)

Actual Results:  
Blank page and error console error

Expected Results:  
Should display XML tree, as per XMLPrettyPrint.xml
Comment 1 Peter Van der Beken [:peterv] 2005-10-01 08:44:41 PDT
Could be fallout from bug 278472. The security check fails in
nsGenericElement::doInsertBefore.
Comment 2 Peter Van der Beken [:peterv] 2005-10-01 09:07:08 PDT
Created attachment 198137 [details] [diff] [review]
v1

The patch for bug 278472 actually tightened a security check (we used to set
old_doc to newContent->GetDocument() in InsertBefore but now we set it to
newContent->GetOwnerDoc()). This uncovered a bug in
nsXMLPrettyPrinter::PrettyPrint: we pass the pretty-print stylesheet as the
document to use for creating a document fragment and then insert that document
fragment into the document being pretty-printed. We should pass the document
that we're going to insert into as the document to use for creating the
document fragment.
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-10-02 07:34:47 PDT
Comment on attachment 198137 [details] [diff] [review]
v1

r+sr=bzbarsky.	We should get this on branch ASAP...
Comment 4 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-10-02 07:36:32 PDT
Peter, do you think I should go back to using GetCurrentDoc() there?  It seems
like that opens us up to security holes....
Comment 5 Mike Shaver (:shaver -- probably not reading bugmail closely) 2005-10-02 08:14:25 PDT
Comment on attachment 198137 [details] [diff] [review]
v1

a=shaver to fix this regression from security fix.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-10-02 08:54:24 PDT
Fixed on trunk and 1.8 branch.  Thanks for dealing, Peter!
Comment 7 Jonathan Stanley 2005-10-02 18:52:00 PDT
Confirm fixed in Firefox build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051002
Firefox/1.6a1 ID:2005100216
Comment 8 Peter Van der Beken [:peterv] 2005-10-03 10:33:38 PDT
(In reply to comment #4)
> Peter, do you think I should go back to using GetCurrentDoc() there?  It seems
> like that opens us up to security holes....

I think we should keep GetOwnerDoc() there if it doesn't cause any serious issues.

Note You need to log in before you can comment on or make changes to this bug.