I minimised that crash as much as possible: http://www.damowmow.com/mozilla/crash/4.html http://www.damowmow.com/mozilla/crash/4.xml ...but I couldn't get it to crash without the XBL. Here is the CSS (minus comments): .bind { -moz-binding: url(4.xml#test); } .test:active { float: right; } Here's the XBL (complete): <?xml version="1.0"?> <bindings xmlns="http://www.mozilla.org/xbl" xmlns:html="http://www.w3.org/1999/xhtml"> <binding id="test"> <content> <html:div><children/></html:div> </content> </binding> </bindings> Here's the HTML (the fragment required to crash): <div class="bind"> <div class="test"> click me </div> </div> It also happens if instead of setting the DIV to float:right on :active, you set it to position:relative, or position:absolute, or display:table, or display:inline, or overflow:scroll, or... probably anything that requires a reframe. It works fine without the XBL.

Nominating for RTM. This is a very easy way for a malicious author to crash an end user system using mail. All you need to do is send an e-mail that uses two lines of CSS and a minimal XBL file and boom, the entire app dies. This could also happen with the instant messenger client -- send some HTML that happens to bind this simple XML, and boom.

rtm need info

Ok, here's the deal. Only XUL supports dynamically removing and inserting kids under XBL insertion points. Everyone else screws that up right now. This is the subject of 51264, so add yourself to the cc list to track that problem. The crash itself happens whenever an attempt is made to remove a child that isn't really found under the block frame, so given the setup A -> (B) -> C, where C is anonymous, because of 51264, I try to remove C from A. This exposes a crash in the block frame code. That crash is bug #56894, and it has been rtm++, so I'm going to close this bug as a dup of that one. Hixie, please add your test case links for test 4 to 51264, so that when I get around to fixing that bug, I'll have a test case that I can use to verify. Thanks!

I meant B was anonymous not C.

*** This bug has been marked as a duplicate of 56894 ***

Turns out this isn't quite a duplicate. The patch attached to bug 56894 *does* fix this bug, but it does not fix that bug completely. So, I'm checking in that fix to the branch, and transfering over the stats: patch by rickg r=buster a=waterson

fix checked into trunk. awaiting PDT approval to check this into branch. The patch has already been approved as rtm++ under bug 56894, but that doesn't automatically mean it gets rtm++ here. PDT, please re-evaluate. This patch fixes this set of crashes, and is necessary but not sufficient to fix the crasher in bug 56894.

assigned to me

fix checked into trunk.

rtm++ on this one too. Please land as soon as possible.

Since buster can't check in right now, this bug moves to the limbo list. This fix has missed the first N6 candidate build, so we can not take it unless we respin. This bug is in candidate limbo. We will reconsider this fix once we have a candidate in hand, but we can't take this fix before then. PDT marking [rtm+]

PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to the branch. Please check in ASAP.

fix checked into branch

with a Macintosh build from 2000103114, I can't reproduce this crash by loading the url above.

Loading http://www.damowmow.com/mozilla/crash/4.html does not crash. I clicked on the single line of text which caused that line to get duplicated. No crash occurred. Verified with 10-31-14 rtm branch build on NT. Marking with vtrunk keyword so that this bug gets verified on the trunk.

I still see this with Linux trunk build 2000110421. No crash, but browser hangs.

Using build 200110420 Trunk. This URL crash my Mozilla. I can 100% reproduce this. Open URl and click on the text and mozilla is dead ! (URL:http://www.damowmow.com/mozilla/crash/4.html)

I have used the wrong words ! No crash, but browser hangs *Sorry for the SPAM*

In the current branch candidate builds this neither hangs nor crashes. In order to distinguish between the code bases, and since the behaviour has changed from the originally reported bug, I have filed bug 59210, and CC'ed the people on this bug. Given no hang, no crash for the branch. Marking this FIXED again. But many thanks to Boris and Matthias for noting this problem and reopening.

verified for 20001103 MN6 builds. The other bug will deal with the hang condition for the trunk bits (die, branch, die!!).

Verified Fixed on Mozilla trunk builds. hang, no crash. linux 110606 RedHat 6.2 win32 110104 NT 4 mac 110108 Mac OS9 Setting bug to Verified and removing vtrunk keyword.