Closed Bug 458637 Opened 11 years ago Closed 11 years ago
[FIX]"ASSERTION: unexpected second call to Set
Initial Child List" and more with XSLT
Steps to reproduce: 1. Save the attachments as b3.html and inner.xhtml 2. Open b3.html Result: ###!!! ASSERTION: initial containing block already created: 'nsnull == mInitialContainingBlock', file /Users/jruderman/central/layout/base/nsCSSFrameConstructor.cpp, line 8745 ###!!! ASSERTION: unexpected second call to SetInitialChildList: 'Not Reached', file /Users/jruderman/central/layout/generic/nsContainerFrame.cpp, line 111 ###!!! ASSERTION: Some objects allocated with AllocateFrame were not freed: 'mFrameCount == 0', file /Users/jruderman/central/layout/base/nsPresShell.cpp, line 676 Security-sensitive for now because the last assertion scares me. Based on the crashtest for bug 428844. Related to bug 61675?
So the issue is that we swap in the new document into the viewer while the subframe is hidden. Then we do a BeginUpdate() before inserting the root content, which processes restyles and unhides the subframe. Since we didn't flag the transformation result as not being ready for initial reflow yet, the document viewer does said initial reflow. Then we insert the root, which effectively double-notifies on it, hence the asserts. Fix coming up.
Summary: "ASSERTION: unexpected second call to SetInitialChildList" and more with XSLT → [FIX]"ASSERTION: unexpected second call to SetInitialChildList" and more with XSLT
Please check in as a crashtest (hopefully crashtests will one day fail on assertions)
Pushed changeset 95e6729d8079. I didn't check in the test yet, because this is still security-sensitive.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 342382 [details] [diff] [review] Fix Simple fix; should take on branch.
Attachment #342382 - Flags: approval220.127.116.11?
Comment on attachment 342382 [details] [diff] [review] Fix Approved for 18.104.22.168, a=dveditz for release-drivers
Attachment #342382 - Flags: approval22.214.171.124? → approval126.96.36.199+
Fixed for 188.8.131.52.
Tomcat, could you verify this one for 184.108.40.206 as well since you have a debug build?
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11pre) Gecko/2008102800 Firefox/3.0.4pre - i don't see the assertion from comment #0 when using the testcase from Jesse. --> Verified fixed1.9.04
Depends on: 473680
11 years ago
Depends on: 473968
You need to log in before you can comment on or make changes to this bug.