User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 Assume a XHTML-page uses Stylesheet A which imports (via <xsl:import>) another stylesheet B which again imports a stylesheet C, then any templates (and other stuff) inside of stylesheet C will be ignored. While Mozilla 1.1 processed cases like this correctly Mozilla 1.2b does not. You may get a small test suite that demonstrates the problem: http://home.tu-clausthal.de/~ifbf/mozilla-test/mozilla-test.zip All test pages (test1.xml to test3.xml) should render similar, but they don't for this bug. Reproducible: Always Steps to Reproduce: 1. Just take a look at http://home.tu-clausthal.de/~ifbf/mozilla-test/test3.xml and compare it with http://home.tu-clausthal.de/~ifbf/mozilla-test/test2.xml and test1.xml Actual Results: Page 3 doesn't render like Page 2 or Page 1 Expected Results: All should render pretty equal I tested only Mozilla 1.2b for win32 but I can't imagine that this is an OS-specific problem.
this is due to the fact that @mozilla.org/content/syncload-dom-service;1 doesn't set the mDocumentBaseURI of nsDocument. Not sure if it should use nsDocument::ResetToURI or so. XSLT is wrong component, but there ain't a right one. Reassigning to sicking, he did that. Anybody else may cheer and grab that bug, I guess.
Assignee: peterv → bugmail
Status: UNCONFIRMED → NEW
Ever confirmed: true
i'll investigate. This sounds bad
Component: XSLT → XML
*** Bug 182172 has been marked as a duplicate of this bug. ***
*** Bug 187490 has been marked as a duplicate of this bug. ***
The problem is that the syncloader doesn't reset the document so it therefor doesn't have a base-uri (and probably misses a few other things as well). However just chaning aReset from PR_FALSE to PR_TRUE in the call to StartDocumentLoad since that will drop the loadlistener that we have attached. Unfortunatly it is dangerous to add the loadlistener after calling StartDocumentLoad since if that fails we will be left with a circular ownership between sink->document->scriptloader->sink. I've removed that circle in bug 188729 so adding a dependency on that. Once that is fixed it is however easy enough to just attach the loadlistener after StartDocumentLoad is called.
Depends on: 188729
*** Bug 174372 has been marked as a duplicate of this bug. ***
*** Bug 184249 has been marked as a duplicate of this bug. ***
Created attachment 111321 [details] [diff] [review] patch to fix this should not go in until bug 188729 is fixed
Status: NEW → ASSIGNED
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → mozilla1.3beta
Comment on attachment 111321 [details] [diff] [review] patch to fix mmmm shorter code.... (add a one-line comment about why we start the load before attaching the listener, ok?)
Attachment #111321 - Flags: superreview?(bzbarsky) → superreview+
Attachment #111321 - Flags: review?(peterv) → review+
fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
*** Bug 190299 has been marked as a duplicate of this bug. ***
*** Bug 196153 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.