Last Comment Bug 407152 - ASSERTION: reflowing in the middle of frame construction with onoverflow, bindings and iframe
: ASSERTION: reflowing in the middle of frame construction with onoverflow, bin...
Status: RESOLVED WORKSFORME
[sg:critical?]
: assertion, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 395609
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-06 07:51 PST by Martijn Wargers [:mwargers] (not working for Mozilla)
Modified: 2014-11-03 11:43 PST (History)
14 users (show)
roc: blocking1.9-
dveditz: wanted1.8.1.x?
mats: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (910 bytes, application/vnd.mozilla.xul+xml)
2007-12-06 07:51 PST, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details

Description Martijn Wargers [:mwargers] (not working for Mozilla) 2007-12-06 07:51:20 PST
Created attachment 291886 [details]
testcase

See testcase, which triggers this assertion for me in current debug trunk build:
###!!! ASSERTION: reflowing in the middle of frame construction: 'mPresContext->
mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file c:\mozilla-build\mozilla\layo
ut\base\nsPresContext.h, line 929

Maybe this is an event handling issue, because I use onoverflow?

The first binding has a field that calls getBoxObjectFor on the root element.
The second binding is just an empty binding.
Comment 1 Jesse Ruderman 2007-12-06 21:31:42 PST
I can reproduce on Mac.
Comment 2 Boris Zbarsky [:bz] 2007-12-06 23:21:02 PST
Usual deal.  This is the relevant part of the stack:

#23 0xb4c8a7e4 in nsFrameLoader::Destroy (this=0xb19eee78)
    at ../../../../mozilla/content/base/src/nsFrameLoader.cpp:265
#24 0xb4a53828 in nsSubDocumentFrame::Destroy (this=0x87aa8b4)
    at ../../../mozilla/layout/generic/nsFrameFrame.cpp:739

That stops the loadgroup, which fires onload.  In this case, the onload layout flush is what's causing the assert, but we could have script running there just as easily.

I swear we have bugs on this....
Comment 3 Olli Pettay [:smaug] 2007-12-07 02:03:37 PST
We have: Bug 395609 is one, and IIRC there are more
Comment 4 Jesse Ruderman 2008-01-16 15:47:46 PST
bz et al, is this likely to be exploitable?
Comment 5 Boris Zbarsky [:bz] 2008-01-16 16:15:15 PST
Yes.
Comment 6 Mike Schroepfer 2008-01-21 18:19:26 PST
Given comment #5 moving to blocking list
Comment 7 Jesse Ruderman 2008-02-29 16:52:13 PST
WFM on Mac.  I get an error message about seeing </binding> but expecting </content>.
Comment 8 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-03-22 14:26:39 PDT
Yeah, also worksforme here on current windows debug trunk build.
Comment 9 Boris Zbarsky [:bz] 2008-03-22 18:35:56 PDT
Could _really_ use a test.
Comment 10 Jesse Ruderman 2008-03-22 19:41:17 PDT
I'd check in the testcase as a crashtest if this bug wasn't security-sensitive.
Comment 11 Boris Zbarsky [:bz] 2008-03-22 22:21:34 PDT
Well... is this a problem on branch?
Comment 12 Jesse Ruderman 2008-03-22 22:39:16 PDT
It might be hard to tell, since the 1.8 branch doesn't have the "reflowing in the middle of frame construction" assertion.
Comment 13 Jonas Sicking (:sicking) PTO Until July 5th 2008-03-24 10:04:23 PDT
What have we done in similar cases? Don't lots of our current crash tests crash on branch, possibly exploitably?
Comment 14 Mats Palmgren (vacation) 2014-11-02 14:55:45 PST
Landed the crashtest:
https://hg.mozilla.org/integration/mozilla-inbound/rev/31c3029265eb
Comment 15 Carsten Book [:Tomcat] 2014-11-03 04:05:24 PST
https://hg.mozilla.org/mozilla-central/rev/31c3029265eb

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