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.
I can reproduce on Mac.
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....
We have: Bug 395609 is one, and IIRC there are more
10 years ago
bz et al, is this likely to be exploitable?
Given comment #5 moving to blocking list
WFM on Mac. I get an error message about seeing </binding> but expecting </content>.
Yeah, also worksforme here on current windows debug trunk build.
Could _really_ use a test.
I'd check in the testcase as a crashtest if this bug wasn't security-sensitive.
Well... is this a problem on branch?
It might be hard to tell, since the 1.8 branch doesn't have the "reflowing in the middle of frame construction" assertion.
What have we done in similar cases? Don't lots of our current crash tests crash on branch, possibly exploitably?
Landed the crashtest: https://hg.mozilla.org/integration/mozilla-inbound/rev/31c3029265eb