Open Bug 421469 Opened 16 years ago Updated 2 years ago

[meta] [CSS21] Pass Simon Pieters' magic-body tests

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

People

(Reporter: zcorpan, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: meta)

Does this have anything to do with body being magic, or is it just that when there are multiple body elements we choose the last one whereas the spec says to choose the first?  (Or is it that our DOM-based code chooses the last one, but in HTML the parser drops all later body elements whereas in XHTML we end up with multiple BODY elements?)
s/with body being magic/with XHTML being magic/
The test cases are unrelated to what happens in the HTML parser.

The failures also have nothing to do with Mozilla doing different things in HTML and XHTML (since the equivalent HTML and XHTML tests fail).

For http://simon.html5.org/test/css/magic-body/background-color/006-declarative.xht and http://simon.html5.org/test/css/magic-body/overflow/006-declarative.xht the DOM is:

html
- head
- - ...
- body
- - ...
- body id='test'

...where 'background'/'overflow' on #test applies to the viewport, which it should not (only the first body should be magic).

For http://simon.html5.org/test/css/magic-body/overflow/004.xht the DOM is initially:

html
- head
- - ...
- body
- - ...

...and then, when the script has run:

html
- head
- - ...
- body (in the urn:foo:bogus namespace)
- - ...

...where the 'overflow' for the new non-HTML body element should not apply to the viewport.

HTH,
So you're saying there are two bugs:

1) the code that deals with multiple <body> elements (nsHTMLDocument::GetBodyContent) picks the last body element instead of the first

2) handling of dynamic changes when an element transitions from being "the body" to not being "the body" isn't working correctly, because we're only doing special handling for elements that are "the body" (in ApplyRenderingChangeToTree in nsCSSFrameConstructor.cpp, and somewhere else for 'overflow', I'm hoping)?  (And that we don't have any special handling to look at the "new body" when the body changes?)

Are those right?  If so, they should probably be reported and tracked as two separate bugs (maybe dependencies of this one?).

Is there a third bug on not handling dynamic changes of 'overflow' on the body at all?  Or does that work?
Yeah, although for (2) it's not actually the same element -- the script creates a new element and swaps it for the old one.

The other tests do dynamic things with the body, so dynamic changes of 'overflow' on the body seems to work in general.
Ah, so we probably don't have code to handle the removal of a body element, when that removal can affect the viewport's scrollbar state.
OK, confirming bug, and making it cover only (2); we should probably also test what happens when:
 (1) the root element is removed or added
 (2) the document's body changes due to insertion or removal of another body element
 (3) when the only body element is removed or added
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: [CSS21] Magic <body> edge cases → [CSS21] Magic <body> edge cases not handled correctly when a <body> is removed
Er, morphing bugs is a bad idea; I'll file a new one.
Summary: [CSS21] Magic <body> edge cases not handled correctly when a <body> is removed → [CSS21] Magic <body> edge cases
I filed bug 459924.

Actually, I'll morph to more general and make this a meta-bug for passing all the tests, and thus also depend on bug 379461.
Depends on: 379461
Keywords: meta
Summary: [CSS21] Magic <body> edge cases → [CSS21] Pass Simon Pieter's magic-body tests
Summary: [CSS21] Pass Simon Pieter's magic-body tests → [CSS21] Pass Simon Pieters' magic-body tests
Severity: normal → S3
Summary: [CSS21] Pass Simon Pieters' magic-body tests → [meta] [CSS21] Pass Simon Pieters' magic-body tests
You need to log in before you can comment on or make changes to this bug.