Closed Bug 460803 (CVE-2008-5500) Opened 16 years ago Closed 16 years ago

[FIX]PresShell::InitialReflow "ASSERTION: Why are we being called?" with XUL iframe

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: bzbarsky)

References

Details

(4 keywords, Whiteboard: [sg:critical?])

Attachments

(3 files, 1 obsolete file)

About 50% of the time, loading the testcase triggers these six assertions:

1. ###!!! ASSERTION: Why are we being called?: '!mDidInitialReflow', file layout/base/nsPresShell.cpp, line 2373

2. ###!!! ASSERTION: initial containing block already created: 'nsnull == mInitialContainingBlock', file layout/base/nsCSSFrameConstructor.cpp, line 8760

3. ###!!! ASSERTION: Already have an undisplayed context entry for aContent: '!GetUndisplayedContent(aContent)', file layout/base/nsFrameManager.cpp, line 574

4. ###!!! ASSERTION: unexpected mInitialContainingBlock: 'processChildren ? !mInitialContainingBlock : mInitialContainingBlock == contentFrame', file layout/base/nsCSSFrameConstructor.cpp, line 4308

5. ###!!! ASSERTION: unexpected second call to SetInitialChildList: 'Not Reached', file layout/generic/nsContainerFrame.cpp, line 111

6. ###!!! ASSERTION: Why is the root in mDirtyRoots already?: 'mDirtyRoots.IndexOf(rootFrame) == -1', file layout/base/nsPresShell.cpp, line 2462

and then closing it triggers:

7. ###!!! ASSERTION: Some objects allocated with AllocateFrame were not freed: 'mFrameCount == 0', file layout/base/nsPresShell.cpp, line 676
Good stuff.  We get into nsMediaDocument::StartLayout when OnStartRequest fires.  We grab the presshell, start layout on it.  Then we do a synchronous paint, which flushes pending notifications.  That triggers a frame reconstruct in the parent document (from the pending restyle), which blows away the presshell we just started layout, creates a new one, and starts layout on it.  Then we return from the paint call, move on to the next presshell for the document (the newly-created one!) and proceed to try starting layout on it.  Then we lose.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #343977 - Flags: superreview?(jonas)
Attachment #343977 - Flags: review?(jonas)
The key here is that the image needs to come in after the attr set happened but before the restyle is processed.  Fun.  :(  Not sure how to guarantee that in a test.
Summary: PresShell::InitialReflow "ASSERTION: Why are we being called?" with XUL iframe → [FIX]PresShell::InitialReflow "ASSERTION: Why are we being called?" with XUL iframe
Attachment #343977 - Flags: superreview?(jonas)
Attachment #343977 - Flags: superreview+
Attachment #343977 - Flags: review?(jonas)
Attachment #343977 - Flags: review+
Pushed changeset f05dd60fa3ed.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Attachment #343977 - Flags: approval1.9.0.4?
Comment on attachment 343977 [details] [diff] [review]
Do it like the sinks

I do think that we should take this on branch, but I'd request apprval11.9.0.5 (not .4) if I could...
Attached patch 1.8 branch patch (obsolete) — Splinter Review
Again, I'd probably try for the next branch release not this very next one.
Attachment #344162 - Flags: approval1.8.1.18?
Attachment #344162 - Attachment is obsolete: true
Attachment #344163 - Flags: approval1.8.1.18?
Attachment #344162 - Flags: approval1.8.1.18?
Attachment #343977 - Flags: approval1.9.0.4? → approval1.9.0.5?
Attachment #344163 - Flags: approval1.8.1.18? → approval1.8.1.19?
Flags: blocking1.9.0.5+
Flags: blocking1.8.1.19+
Whiteboard: [sg:critical?]
Comment on attachment 343977 [details] [diff] [review]
Do it like the sinks

approved for 1.9.0.5 and 1.8.1.19, a=dveditz for release-drivers

(please watch tinderbox for the tree to open before landing)
Attachment #343977 - Flags: approval1.9.0.5? → approval1.9.0.5+
Attachment #344163 - Flags: approval1.8.1.19? → approval1.8.1.19+
Fixed on both branches.
verified fixed for 1.8.1.19 - using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.20pre) Gecko/2008120304 Firefox/2.0.0.20pre (1.8.1 Debug Build) and the Testcase from Jesse.

I do not see the Assertions from Comment #0, only ###!!! ASSERTION: Adding child where we already have a child?  This will likely misbehave: 'Error', file /work/mozilla/builds/1.8.1/mozilla/xpfe/components/shistory/src/nsSHEntry.cpp, line 580, which is a different Bug.

--> Verified fixed 1.8.1.19
also verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6pre) Gecko/2008120309 Firefox/3.0.6pre (Debug Build) and the testcase from Jesse. I do not see the Assertions from Comment #0 when using the Testcase

--> Verified 1.9.0.5
Comment on attachment 344163 [details] [diff] [review]
1.8 branch non-ugly patch

a=asac for 1.8.0
Attachment #344163 - Flags: approval1.8.0.next+
Flags: blocking1.8.0.next+
Alias: CVE-2008-5500
Group: core-security
You need to log in before you can comment on or make changes to this bug.