This fairly simple testcase triggers: ###!!! ASSERTION: mOriginalDisplay has not been properly initialized: 'mStyleDisplay->mOriginalDisplay != NS_STYLE_DISPLAY_NONE', file /Users/jruderman/central/layout/generic/nsHTMLReflowState.cpp, line 882 Regression from bug 243519, perhaps?
We create (and reflow) a frame for the root content even though the style context has mDisplay == NS_STYLE_DISPLAY_NONE. My gut feeling is that Opera and Safari is correct in not displaying the text in the second testcase, but I haven't checked the CSS spec. Does anyone know?
http://www.w3.org/TR/CSS21/visuren.html#propdef-display "Descendant elements do not generate any boxes either;" and a little later: "For the root element, the computed value is changed as described in the section on the relationships between 'display', 'position', and 'float'." (9.7) http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo "1. If 'display' has the value 'none', then 'position' and 'float' do not apply. In this case, the element generates no box" So I think it's clear that we should not display the text.
Comment on attachment 338009 [details] [diff] [review] Like so? looks good to me
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
http://hg.mozilla.org/mozilla-central/rev/3cc51edbb1c9 http://hg.mozilla.org/mozilla-central/rev/9917bfc85075 -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Shouldn't this have added the root element to the undisplayed map so that if its 'display' property were changed dynamically, a frame would get created? Or does that work some other way?
That triggers: ###!!! ASSERTION: undisplayed content must have a parent: 'parent', file /usr/moz/hg3/layout/base/nsFrameManager.cpp, line 581 The frame manager stores the undisplayed map using the parent pointer as a hash key. It's bug 283686 I think.
Could this bug have caused a serious scroll delay on http://westseattleblog.com/blog/?page_id=432 (testcase from Bug 484572)?
You need to log in before you can comment on or make changes to this bug.