Closed
Bug 212563
Opened 21 years ago
Closed 21 years ago
[FIXr]crash in GlobalWindowImpl::HandleDOMEvent involving document.write to frameset
Categories
(Core :: DOM: Events, defect, P1)
Core
DOM: Events
Tracking
()
VERIFIED
FIXED
mozilla1.6beta
People
(Reporter: jruderman, Assigned: bzbarsky)
References
Details
(Keywords: crash, testcase)
Attachments
(2 files)
125 bytes,
text/html
|
Details | |
933 bytes,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
Loading this testcase crashes Moz: <frameset resizable="yes" rows="100%"> <frame src="data:text/html,<body onload=top.document.write('foo')>"> </frameset> (Instead of crashing, it should appear as a document with the text "foo", which is what happens with equivalent code in IE.) Stack trace: 006f006e() > xpcom.dll!nsQueryInterface::operator()(const nsID & aIID={...}, void * * answer=0x0012f1a8) Line 47 + 0x19 C++ jsdom.dll!nsCOMPtr<nsIContent>::assign_from_helper(const nsCOMPtr_helper & helper={...}, const nsID & aIID={...}) Line 965 + 0x12 C++ jsdom.dll!nsCOMPtr<nsIContent>::nsCOMPtr<nsIContent>(const nsQueryInterface & helper={...}) Line 550 C++ jsdom.dll!GlobalWindowImpl::HandleDOMEvent(nsIPresContext * aPresContext=0x038ee068, nsEvent * aEvent=0x0012f2f0, nsIDOMEvent * * aDOMEvent=0x0012f2ac, unsigned int aFlags=7, nsEventStatus * aEventStatus=0x0012f2ec) Line 879 C++ gklayout.dll!DocumentViewerImpl::LoadComplete(unsigned int aStatus=0) Line 928 + 0x2f C++ docshell.dll!nsDocShell::EndPageLoad(nsIWebProgress * aProgress=0x038fff2c, nsIChannel * aChannel=0x03900770, unsigned int aStatus=0) Line 4328 C++ docshell.dll!nsWebShell::EndPageLoad(nsIWebProgress * aProgress=0x038fff2c, nsIChannel * channel=0x03900770, unsigned int aStatus=0) Line 816 C++ docshell.dll!nsDocShell::OnStateChange(nsIWebProgress * aProgress=0x038fff2c, nsIRequest * aRequest=0x03900770, unsigned int aStateFlags=131088, unsigned int aStatus=0) Line 4260 C++ docshell.dll!nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * aProgress=0x038fff2c, nsIRequest * aRequest=0x03900770, int aStateFlags=131088, unsigned int aStatus=0) Line 1231 C++ docshell.dll!nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * request=0x03900770, unsigned int aStatus=0) Line 869 C++ docshell.dll!nsDocLoaderImpl::DocLoaderIsEmpty() Line 767 C++ docshell.dll!nsDocLoaderImpl::OnStopRequest(nsIRequest * aRequest=0x03900770, nsISupports * aCtxt=0x00000000, unsigned int aStatus=0) Line 697 C++ necko.dll!nsLoadGroup::RemoveRequest(nsIRequest * request=0x03900770, nsISupports * ctxt=0x00000000, unsigned int aStatus=0) Line 694 + 0x23 C++ necko2.dll!nsDataChannel::OnStopRequest(nsIRequest * request=0x03900770, nsISupports * ctxt=0x00000000, unsigned int status=0) Line 572 C++ necko.dll!nsOnStopRequestEvent0::HandleEvent() Line 319 + 0x21 C++ necko.dll!nsStreamListenerEvent0::HandlePLEvent(PLEvent * aEvent=0x03901d80) Line 113 + 0xc C++ xpcom.dll!PL_HandleEvent(PLEvent * self=0x03901d80) Line 671 + 0xa C xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x002ac558) Line 606 + 0x9 C xpcom.dll!_md_EventReceiverProc(HWND__ * hwnd=0x00b102a8, unsigned int uMsg=49435, unsigned int wParam=0, long lParam=2803032) Line 1412 + 0x9 C user32.dll!77d43a68() user32.dll!77d43b37() user32.dll!77d43d91() user32.dll!77d43df7() appshell.dll!nsAppShellService::Run() Line 479 C++ mozilla.exe!main1(int argc=1, char * * argv=0x002a50b8, nsISupports * nativeApp=0x009ecd38) Line 1291 + 0x20 C++ mozilla.exe!main(int argc=1, char * * argv=0x002a50b8) Line 1670 + 0x25 C++ mozilla.exe!mainCRTStartup() Line 400 + 0x11 C kernel32.dll!77e814c7() I discovered this by pasting something like <frameset resizable="yes" rows="100%"> <frame src="editbox.html"> </frameset> into http://www.squarefree.com/htmledit/.
Reporter | ||
Comment 1•21 years ago
|
||
Comment 3•21 years ago
|
||
Changing to All, since confirmed with 2003-08-09-06 cvs on MacOSX.
BTW,
> it should appear as a document with the text "foo", which
> is what happens with equivalent code in IE.
I don't think so, although the crashing is a bug.
OS: Windows XP → All
Hardware: PC → All
Comment 4•21 years ago
|
||
Bug 224073 may be a duplicate.
Comment 5•21 years ago
|
||
*** Bug 224073 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 6•21 years ago
|
||
Assignee | ||
Comment 7•21 years ago
|
||
Taking bug.
Assignee: saari → bz-vacation
Priority: -- → P1
Summary: crash in GlobalWindowImpl::HandleDOMEvent involving document.write to frameset → [FIX]crash in GlobalWindowImpl::HandleDOMEvent involving document.write to frameset
Target Milestone: --- → mozilla1.6beta
Assignee | ||
Comment 8•21 years ago
|
||
Comment on attachment 134397 [details] [diff] [review] Patch jst, would you review? The problem here, of course, is that the event to the subframe window is dispatched after the whole frameset is torn down... at that point the window is holding a bogus weak ref to an already-deleted frame element. I put the SetFrameElementInternal in the framaloader, since that's where the value is set to start with, but it may be safer to put it in the Destroy method of the docshell... your call, in any case. I preferred this way because it keeps all the "FrameElementInternal" stuff together.
Attachment #134397 -
Flags: superreview?(jst)
Attachment #134397 -
Flags: review?(jst)
Comment 9•21 years ago
|
||
Comment on attachment 134397 [details] [diff] [review] Patch Yeah, this looks fine to me. r+sr=jst
Attachment #134397 -
Flags: superreview?(jst)
Attachment #134397 -
Flags: superreview+
Attachment #134397 -
Flags: review?(jst)
Attachment #134397 -
Flags: review+
Assignee | ||
Updated•21 years ago
|
Summary: [FIX]crash in GlobalWindowImpl::HandleDOMEvent involving document.write to frameset → [FIXr]crash in GlobalWindowImpl::HandleDOMEvent involving document.write to frameset
Assignee | ||
Comment 10•21 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 11•17 years ago
|
||
Reftest checked in. I changed the testcase to use an outer iframe because top-level document.writes confuse reftest. I checked to make sure the new testcase still triggered the crash in Mozilla 1.6a.
Status: RESOLVED → VERIFIED
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•