Closed Bug 454361 Opened 15 years ago Closed 15 years ago

"ASSERTION: mOriginalDisplay has not been properly initialized"

Categories

(Core :: Layout: Positioned, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: assertion, regression, testcase)

Attachments

(4 files)

Attached file testcase
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?
OS: Mac OS X → All
Hardware: PC → All
Attached file Testcase #2
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?
Attached patch Like so?Splinter Review
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
Attachment #338009 - Flags: superreview+
Attachment #338009 - Flags: review+
Attached patch reftest.diffSplinter Review
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: 15 years ago
Flags: wanted1.9.0.x?
Flags: in-testsuite+
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.
Depends on: 468211
Flags: wanted1.9.0.x? → wanted1.9.0.x+
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.