"ASSERTION: mOriginalDisplay has not been properly initialized"

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: jruderman, Assigned: mats)

Tracking

(Blocks 1 bug, {assertion, regression, testcase})

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

Reporter

Description

11 years ago
Posted 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?
Assignee

Updated

11 years ago
OS: Mac OS X → All
Hardware: PC → All
Assignee

Comment 1

11 years ago
Posted file Testcase #2
Assignee

Comment 2

11 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

11 years ago
Posted patch Like so?Splinter Review
Assignee

Comment 4

11 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

11 years ago
Posted patch reftest.diffSplinter Review
Assignee: nobody → mats.palmgren
Status: NEW → ASSIGNED
Assignee

Comment 7

11 years ago
http://hg.mozilla.org/mozilla-central/rev/3cc51edbb1c9
http://hg.mozilla.org/mozilla-central/rev/9917bfc85075

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 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

11 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.
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.