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

Could be fallout from bug 278472. The security check fails in nsGenericElement::doInsertBefore.

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 on attachment 198137 [details] [diff] [review] v1 r+sr=bzbarsky. We should get this on branch ASAP...

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.

Fixed on trunk and 1.8 branch. Thanks for dealing, Peter!

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

(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.