Last Comment Bug 537624 - "ASSERTION: Already have an undisplayed context entry for aContent" with {ib}
: "ASSERTION: Already have an undisplayed context entry for aContent" with {ib}
Status: RESOLVED FIXED
: assertion, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Mac OS X
: P1 normal (vote)
: mozilla14
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
: Jet Villegas (:jet)
Mentors:
Depends on:
Blocks: stirdom 480979 597317 615012 618428 736924
  Show dependency treegraph
 
Reported: 2010-01-03 13:32 PST by Jesse Ruderman
Modified: 2012-03-20 03:52 PDT (History)
7 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
?


Attachments
testcase (381 bytes, text/html)
2010-01-03 13:32 PST, Jesse Ruderman
no flags Details
Proposed fix (18.04 KB, patch)
2012-03-19 11:26 PDT, Boris Zbarsky [:bz] (still a bit busy)
roc: review+
Details | Diff | Splinter Review
Additional fix needed on top of the first patch to fix leaks (1.96 KB, patch)
2012-03-19 12:42 PDT, Boris Zbarsky [:bz] (still a bit busy)
roc: review+
Details | Diff | Splinter Review

Description Jesse Ruderman 2010-01-03 13:32:30 PST
Created attachment 419836 [details]
testcase

###!!! 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
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2010-01-15 20:31:58 PST
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?
Comment 2 Robert O'Callahan (:roc) (email my personal email if necessary) 2010-01-16 01:41:03 PST
Nope.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2012-03-19 08:51:04 PDT
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.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2012-03-19 11:26:44 PDT
Created attachment 607228 [details] [diff] [review]
Proposed fix
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2012-03-19 12:42:15 PDT
Created attachment 607263 [details] [diff] [review]
Additional fix needed on top of the first patch to fix leaks

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).
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2012-03-19 15:36:39 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/b595743d74b6
Comment 7 Mounir Lamouri (:mounir) 2012-03-20 03:52:03 PDT
https://hg.mozilla.org/mozilla-central/rev/b595743d74b6

Note You need to log in before you can comment on or make changes to this bug.