Closed Bug 336960 Opened 14 years ago Closed 13 years ago
Crash when window gets destroyed when constructor of xbl is running
This is probably another bug that is depending on bug 267833. Marking security sensitive, just to be sure. The testcase also crashes Mozilla1.7. Talkback ID: TB18391641E 0x00000000 nsCSSFrameConstructor::WipeContainingBlock nsCSSFrameConstructor::ContentInserted
Argh, the previous html+xbl in iframe for testcase was wrong, uploading correct files.
Yeah, this is definitely bug 267833 fodder...
The testcase doesn't work online anymore, I filed bug 373536 for that. It seems to work offline, and there it doesn't crash anymore in current trunk builds, so this bug seems fixed by bug 267833, but I'd like to test this again as soon as bug 373536 is fixed.
Never mind, this bug is fixed by bug 267833. I was able to test this locally, because when saving the testcase, it had become slightly (but significantly) different from the online version. So the offline test was a good test to see whether this was fixed. Marking fixed now.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
looks like the test case still crashes Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/2007030919 Firefox/184.108.40.206 should the patches in bug 267833 be consider for the branch? http://talkback-reports.mozilla.org/search/private.jsp?search=2&type=iid&id=30500345 testing bug 336960 and bug 336960 Since Last Crash 3098 sec Total Uptime 88999 sec Trigger Reason 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]
Not clear this is exploitable, and the proposed fix in bug 267833 still has open regressions. Not blocking, wanted, will most likely consider for a later release.
The fix for bug 267833 depends on significant trunk work, and in its own right is not something that I'd consider safe to land on branches. I fully expect it to take me months to shake out the regressions.
Flags: wanted1.8.1.x+ → wanted1.8.1.x?
Whiteboard: [sg:nse?] probably null-deref
WFM in Firefox 220.127.116.11, appears to have been fixed when we landed bug 267833
crash test landed http://hg.mozilla.org/mozilla-central/rev/6ad02f8a56ad
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.