regular text seem to be rendered in white instead of black; < > = are not visible as well

RESOLVED FIXED in mozilla1.8alpha1



15 years ago
14 years ago


(Reporter: Alexandre, Assigned: bz)



Firefox Tracking Flags

(Not tracked)




(1 attachment)



15 years ago
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 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
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
<bz> biesi: and
<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
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.
Attachment #145913 - Flags: superreview?(peterv)
Attachment #145913 - Flags: review?(bugmail)
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.
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.