User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040110 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040110 In the page at http://perso.wanadoo.fr/alexandre.l/poetry/poetry.xsl the < > should be visible, same things for the = and the text between tags, the buttons for expending and reducing nodes are not visible either. Note: the invisible text can be seen by selecting it. Reproducible: Always Steps to Reproduce: 1. Load http://perso.wanadoo.fr/alexandre.l/poetry/poetry.xsl 2. Watch Actual Results: The XML file isn't correctly rendered Expected Results: It should have rendered the regular text in black
<bz> biesi: see http://lxr.mozilla.org/seamonkey/source/content/xml/document/src/nsXMLContentSink.cpp#211 <bz> biesi: and http://lxr.mozilla.org/seamonkey/source/content/xml/document/src/nsXMLContentSink.cpp#1173 <bz> biesi: if we have a special root, the fact that we have elements that have presentation is ignored <bz> biesi: which is totally broken <bz> biesi: eg scripts will execute <bz> biesi: stylesheets will load
*** Bug 230581 has been marked as a duplicate of this bug. ***
I tried to download the file in question to create a testcase, and it appears that this effect isn't reproducable when the document is viewed locally. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031208
That's because the link to the stylesheet is a relative url. To sicking; we need a better way to handle this crap.
Assignee: hjtoi-bugzilla → bugmail
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've known about this problem for a while but i'm not really sure what to do about it. This will only happen when trying to view XSLT and XBL documents. I can see 3 "solutions": 1. Remove the code for 'special roots', this will cause XSLT and XBL documents to not be prettyprinted 2. Turn off scripts and stylesheets (and maybe other things too) when we detect a XSLT or XBL document. However this borders on not following some specs. (CC-ing hixie to get his oppinion on this) 3. Leave things as they are now.
2 is fine by me. We've already decided that we're not following the specs for these, so... This only matters for the specific cases of XSLT and XBL, right?
Mind you, making sure the pretty printer always sets colours and backgrounds together would solve this specific case, I think.
Yes, only XBL and XSLT documents are treated this way, if any other type of document contains a script or a stylesheet it won't be prettyprinted at all.
15 years ago
Comment on attachment 145913 [details] [diff] [review] Maybe like this? r=me though i'm not very thrilled about this. The prettyprint code is growing more and more into a hack. What might be nice to do is to once we detect that a page has a special root tell the document to load as data (rather then 'view') and then let the css/script loaders query that value. However I'm not sure that that is worth it at this point. So i'd say go ahead and check this in as is.
Attachment #145913 - Flags: review?(bugmail) → review+
> The prettyprint code is growing more and more into a hack. "Growing"? ;) Note that things would be simpler (or at least clearer) if we had a mWillPrettyPrint boolean about (starting at true, set to false by PIs or a factored element without a special root)....
Comment on attachment 145913 [details] [diff] [review] Maybe like this? Sigh. Someone please file a bug about simplifying the prettyprinting stuff in the XML content sink (with the suggestions from comments 10 and 11).
Attachment #145913 - Flags: superreview?(peterv) → superreview+
Bug 241113 filed.
Assignee: bugmail → bzbarsky
OS: Windows XP → All
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → mozilla1.8alpha
Fixed on 1.8a trunk.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.