The default bug view has changed. See this FAQ.

XMLPrettyPrint broken, Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Jonathan Stanley, Assigned: peterv)

Tracking

({fixed1.8, regression})

Trunk
x86
Windows XP
fixed1.8, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
(Assignee)

Comment 1

12 years ago
Could be fallout from bug 278472. The security check fails in
nsGenericElement::doInsertBefore.
(Assignee)

Comment 2

12 years ago
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.
Attachment #198137 - Flags: superreview?(bzbarsky)
Attachment #198137 - Flags: review?(bzbarsky)
Flags: blocking1.8b5?
(Assignee)

Updated

12 years ago
Blocks: 278472
Comment on attachment 198137 [details] [diff] [review]
v1

r+sr=bzbarsky.	We should get this on branch ASAP...
Attachment #198137 - Flags: superreview?(bzbarsky)
Attachment #198137 - Flags: superreview+
Attachment #198137 - Flags: review?(bzbarsky)
Attachment #198137 - Flags: review+
Attachment #198137 - Flags: approval1.8b5?
Assignee: general → peterv
Peter, do you think I should go back to using GetCurrentDoc() there?  It seems
like that opens us up to security holes....
Comment on attachment 198137 [details] [diff] [review]
v1

a=shaver to fix this regression from security fix.
Attachment #198137 - Flags: approval1.8b5? → approval1.8b5+
Fixed on trunk and 1.8 branch.  Thanks for dealing, Peter!
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8
Resolution: --- → FIXED

Updated

12 years ago
Flags: blocking1.8b5?
(Reporter)

Comment 7

12 years ago
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
(Assignee)

Comment 8

12 years ago
(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.

Updated

9 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.