Closed Bug 75234 Opened 23 years ago Closed 23 years ago

<style> element in XHTML gets displayed twice (?)

Categories

(Core :: XML, defect, P3)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: ian, Assigned: hjtoi-bugzilla)

References

()

Details

(Keywords: testcase, xhtml, Whiteboard: [Hixie-P4][fixinhand])

Attachments

(5 files)

STEPS TO REPRODUCE
  Go to: http://hixie.ch/tests/adhoc/xml/xhtml/001.xml

ACTUAL RESULTS
  /* This should only appear once, and should be the only thing on this page. */

  head, #test { display: block; white-space: pre; }
  /* This should not appear at any point. */

  /* This should only appear once, and should be the only thing on this page. */

EXPECTED RESULTS
  /* This should only appear once, and should be the only thing on this page. */

NOTES
  Copy and paste causes even more dramatic results.
Whiteboard: [Hixie-P4]
I think this would be a rare situation - futuring.

I am not 100% certain I understand why the current behaviour is wrong. If you
set display:block on head, shouldn't it display both style elements? Or does
style element have more important display:none rule? (sorry, I do not remember
exactly what the CSS spec says in this matter, and don't know what the user
agent is required to do here).
Target Milestone: --- → Future
I agree that this can be futured (although not past Mozilla 1.0; this should
IMHO be a Mozilla 1.0 blocker).

The reason this is a bug is that if you look at the source, you'll see that 
the string is only in the document once, not twice. In ua.css, we set <style>
to "display:none" (you'll notice the <title> is not appearing). However in
the test case we end up showing both <style> elements, even though only one
should appear, and we end up showing the one that should appear, *twice*.

This is most definitely a bug. :-)

*** This bug has been marked as a duplicate of 75724 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Ok, not a duplicate. It appears the fix that went in for 75724 didn't fix the
problem. Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Target Milestone: Future → mozilla1.0
by applying javascript:alert(document.documentElement.innerHTML) on the page I get:

<head>
<title>XHTML: showing script and style</title>
<style type="text/css">
head, #test { display: block; white-space: pre; }
/* This should not appear at any point. */

head, #test { display: block; white-space: pre; }
/* This should not appear at any point. */
</style>
<style type="text/css" id="test">
/* This should only appear once, and should be the only thing on this page. */

/* This should only appear once, and should be the only thing on this page. */
</style>
</head>
<body>
</body>
when the file is given a html mimetype it is fine, but when it is given a xml
mimetype it duplicates the contents of style. Looks like a DOM or parser issue.
Note: I've tried this with other <head> elements, and found that they are not
duplicated. Only <style> is duplicated.
Seems like this has improved slightly, but needs a little tweak to fix it
completely...

It appears we do not need to explicitly add the style element's text node in the
sink; somebody else is doing it for us. I haven't tracked down where, but
mCSSLoader->LoadInlineStyle() perhaps. So, the fix is simply removing some code.
The XHTML innerHTML test shows that the content model is correct.

Peter, can you review?
Status: REOPENED → ASSIGNED
Priority: -- → P3
Whiteboard: [Hixie-P4] → [Hixie-P4][fixinhand]
r=peterv though I'd like to understand where the text node does get added. I
couldn't find code for that in nsCSSLoader. And why does this not happen for
HTML? (see
http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLContentSink.cpp#5120)
Target Milestone: mozilla1.0 → mozilla0.9.4
We collect the PCDATA in mText member, and FlushText() will add the style
element's text. HTML probably has to juggle a bit more to cope with bad markup
etc. so it does it differently.
sr=jst
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Marking verified in the Sept 5th build (2001-09-05-05)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: