Closed
Bug 454361
Opened 16 years ago
Closed 16 years ago
"ASSERTION: mOriginalDisplay has not been properly initialized"
Categories
(Core :: Layout: Positioned, defect)
Core
Layout: Positioned
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: assertion, regression, testcase)
Attachments
(4 files)
87 bytes,
text/html
|
Details | |
98 bytes,
text/html
|
Details | |
1003 bytes,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
915 bytes,
patch
|
Details | Diff | Splinter Review |
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?
Assignee | ||
Updated•16 years ago
|
OS: Mac OS X → All
Hardware: PC → All
Assignee | ||
Comment 1•16 years ago
|
||
Assignee | ||
Comment 2•16 years ago
|
||
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?
Assignee | ||
Comment 3•16 years ago
|
||
Assignee | ||
Comment 4•16 years ago
|
||
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+
Assignee | ||
Comment 6•16 years ago
|
||
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/3cc51edbb1c9
http://hg.mozilla.org/mozilla-central/rev/9917bfc85075
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 16 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?
Assignee | ||
Comment 9•16 years ago
|
||
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.
Updated•16 years ago
|
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Comment 10•16 years ago
|
||
Could this bug have caused a serious scroll delay on http://westseattleblog.com/blog/?page_id=432 (testcase from Bug 484572)?
Unlikely
You need to log in
before you can comment on or make changes to this bug.
Description
•