Closed
Bug 537624
Opened 15 years ago
Closed 13 years ago
"ASSERTION: Already have an undisplayed context entry for aContent" with {ib}
Categories
(Core :: Layout, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla14
People
(Reporter: jruderman, Assigned: bzbarsky)
References
Details
(Keywords: assertion, testcase)
Attachments
(3 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
###!!! ASSERTION: Already have an undisplayed context entry for aContent: '!GetUndisplayedContent(aContent)', file /Users/jruderman/central/layout/base/nsFrameManager.cpp, line 398
###!!! ASSERTION: node in map twice: 'Not Reached', file /Users/jruderman/central/layout/base/nsFrameManager.cpp, line 1736
Assignee | ||
Comment 1•15 years ago
|
||
Hmm. So the problem is that undisplayed entries are added during frame construction item creation. They're only cleared during frame destruction. In particular, if we throw away the frame construction items (e.g. due to a WipeContainingBlock) we won't remove the undisplayed entries.
This is bad. Looks like a regression from bug 480979. And this happens in 1.9.2 as well.
My first instinct is to flag frame construction items when frames are constructed from them, and to have the destructor clear the undisplayed map under the content if no frame has been constructed. The other option is to create items for display:none stuff and change the various code the works with item lists to ignore them (and then not construct any frames from them). That sounds annoying, though.
Any other bright ideas?
Blocks: 480979
Nope.
Assignee | ||
Updated•15 years ago
|
blocking2.0: ? → final+
Priority: -- → P2
Assignee | ||
Updated•14 years ago
|
Priority: P2 → P1
blocking2.0: final+ → -
Assignee | ||
Comment 3•13 years ago
|
||
So the approach from comment 1 doesn't work to fix this bug (though it does fix bug 736924), because it fails for the case when a frame construction item list is constructed for an already-existing parent and is then thrown away. In that case there is no parent frame construction item.
Assignee | ||
Comment 4•13 years ago
|
||
Attachment #607228 -
Flags: review?(roc)
Assignee | ||
Updated•13 years ago
|
Whiteboard: [need review]
Attachment #607228 -
Flags: review?(roc) → review+
Assignee | ||
Comment 5•13 years ago
|
||
The first patch leaked on try, because of that placement new clobbering our list which was holding refs to style contexts (and was also looking like an array leak, hence the new destructor call).
Attachment #607263 -
Flags: review?(roc)
Attachment #607263 -
Flags: review?(roc) → review+
Assignee | ||
Comment 6•13 years ago
|
||
Flags: in-testsuite+
Whiteboard: [need review]
Assignee | ||
Updated•13 years ago
|
Target Milestone: --- → mozilla14
Comment 7•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•