Loading this testcase makes Firefox (debug) crash with 0xdddddddc nsBoxFrame::AppendFrames nsFrameManager::AppendFrames nsCSSFrameConstructor::AppendFrames ... Nightlies crash too, but with a slightly different stack trace.
I can reproduce on the Firefox 2 branch, too, so nominating for blocking1.8.1.
Too late for this type of thing, should fix for 18.104.22.168
Usual problem -- the XBL constructor is run while the frame tree is not yet done being constructed, it does some stuff, said stuff triggers a select event firing, which removes the node from the tree (and destroys its frames). Then we unwind and attempt to insert said deleted frames into the tree, dereference 0xdddddddd (in debug builds, or random memory in opt builds), and crash.
Does this happen in 1.8.0.x as well?
Jonas: Can you take a look at this?
By bzs description I don't think we should try to fix this one particular crash since there's a bigger general issue that can cause many different types of crashes. I.e. that we run XBL ctors at unsafe times. I'll try to look in to that issue as i'm whacking XBL and nsCSSFrameCtor interaction in general.
does the "whacking XBL and nsCSSFrameCtor interaction in general" work have bugs or a spec to help tracking the work and its possible impact on fixing this one? be good to add those links here.
Marking blocking for now. Hopefully the fix for 267833 will fix this one.
Doesn't crash now (probably due to the patch in bug 267833).
10 years ago
Moving out to 22.214.171.124 following bug 267833
bug 267833 landed on the branch, fixed126.96.36.199
verified fixed 188.8.131.52 using : Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ja-JP-mac; rv:184.108.40.206) Gecko/2007100816 Firefox/220.127.116.11 - no crash on testcase - adding verified keyword
Crashtest checked in.
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2007123104 Minefield/3.0b3pre and the testcase from this bug - no crash on testcase -> Verified fixed