Closed
Bug 454361
Opened 15 years ago
Closed 15 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•15 years ago
|
OS: Mac OS X → All
Hardware: PC → All
Assignee | ||
Comment 1•15 years ago
|
||
Assignee | ||
Comment 2•15 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•15 years ago
|
||
Assignee | ||
Comment 4•15 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•15 years ago
|
||
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•15 years ago
|
||
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
Comment 8•15 years ago
|
||
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•15 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•15 years ago
|
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Comment 10•15 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
•