See upcoming testcase, which crash Mozilla after clicking for the second time on the alert. Also crashes Mozilla1.7, so no (recent) regression. Talkback ID: TB16399392W 0x00000000 nsCSSFrameConstructor::WipeContainingBlock nsCSSFrameConstructor::ContentInserted Marking security sensitive, because the first line of the stack looks funny. Please unmark the security flag, if this is not a security issue.
Created attachment 215122 [details] testcase The testcase crashes for me after clicking for the second time on the alert.
Ok, online it's not crashing directly. But after the first time clicking back and then clicking another 2 times on the alert makes Mozilla crash. Or you could test the testcase locally.
Created attachment 215124 [details] Backtrace from debug build #0 0xdddddddd in ?? () #1 0x055ccc0b in nsCSSFrameConstructor::WipeContainingBlock(nsFrameConstructorS tate&, nsIFrame*, nsIFrame*, nsIFrame*) (this=0xe7abf48, aState=@0x22f1e8, aContainingBlock=0xe82b82c, aFrame=0xe82b82c, aFrameList=0x0) at c:/mozilla/mozilla/layout/base/nsCSSFrameConstructor.cpp:13220 #2 0x055c5049 in nsCSSFrameConstructor::ContentInserted(nsIContent*, nsIContent *, int, nsILayoutHistoryState*, int) (this=0xe7abf48, aContainer=0x3c10e50, aChild=0xe7ff698, aIndexInContainer=2, aFrameState=0x0, aInReinsertContent=0) at c:/mozilla/mozilla/layout/base/nsCSSFrameConstructor.cpp:9659 #3 0x0561327c in PresShell::ContentInserted(nsIDocument*, nsIContent*, nsIConte nt*, int) (this=0xe72fb38, aDocument=0xe80ddc0, aContainer=0x3c10e50, aChild=0xe7ff698, aIndexInContainer=2) at c:/mozilla/mozilla/layout/base/nsPresShell.cpp:5211 etc..
In a 126.96.36.199-ish debug build clicking alert twice still did it. The crash was below WipeContainingBlock, but similarly used deleted-looking objects ('this' was 0xddddddf9) >nsCachedStyleData::GetStyleData nsStyleContext::GetStyleData nsIFrame::GetStyleData nsIFrame::GetStyleDisplay nsCSSFrameConstructor::WipeContainingBlock ...etc...
Critical security bugs must have owners. If you can't work on this bug please help us find another active owner for it.
jonas, had a chance to look at this enough to figure out if its a bug you can take, or need to pass to others?
I haven't had a chance to look thoroughly yet, but like bz says, I strongly suspect this will get magically fixed when bug 267833 is fixed.
This seems to work fine now in current trunk build, but I have to test the testcase locally, because of bug 373536. This one is fixed now, fixed by bug 267833.
doesn't look fixed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/2007030919 Firefox/184.108.40.206 - should we be considering getting the patches I still crash on the test case using that build. should we be considering the patch for 267833 on the 1.8 branch?
stack for my crash on 220.127.116.11 looks like Access violation Source File, Line No. c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13566 Stack Trace nsCSSFrameConstructor::WipeContainingBlock [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13566] nsCSSFrameConstructor::ContentInserted [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9575] PresShell::ContentInserted [mozilla/layout/base/nsPresShell.cpp, line 5538] nsXBLStreamListener::Load [mozilla/content/xbl/src/nsXBLService.cpp, line 420] DispatchToInterface [mozilla/content/events/src/nsEventListenerManager.cpp, line 144] nsEventListenerManager::HandleEvent [mozilla/content/events/src/nsEventListenerManager.cpp, line 1752] nsDocument::HandleDOMEvent [mozilla/content/base/src/nsDocument.cpp, line 4075] nsXMLDocument::EndLoad [mozilla/content/xml/document/src/nsXMLDocument.cpp, line 657] nsXMLContentSink::DidBuildModel [mozilla/content/xml/document/src/nsXMLContentSink.cpp, line 353] nsExpatDriver::DidBuildModel [mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 1227]
Bug 267833 hasn't landed on branch yet (and lets discuss over there if it should or not).
Marking "wanted" to indicate this at least happens on the branch.
Blocking for now, will talk to Jonas about bug 267833 (and its regressions) for the branch when he's back, or whether there might be a smaller crash band-aide.
I don't think it's worth it trying to patch this one instead of bug 267833 on the branch. We could spend forever patching symptoms while leaving the real problem there.
Not going to land 267833 on the branches with open regressions, so not making this release.
bug 267833 landed on the 1.8 branch and fixed this.
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:18.104.22.168) Gecko/20071004 Firefox/22.214.171.124: Firefox 126.96.36.199 ID:2007100415. No further crashes.