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)

defect

Tracking

()

VERIFIED FIXED
mozilla1.6beta

People

(Reporter: jruderman, Assigned: bzbarsky)

References

Details

(Keywords: crash, testcase)

Attachments

(2 files)

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/.
Confirmed crashes on Linux with moz cvs 20030710 as well.
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
Bug 224073 may be a duplicate.
*** Bug 224073 has been marked as a duplicate of this bug. ***
Attached patch PatchSplinter Review
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
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 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+
Summary: [FIX]crash in GlobalWindowImpl::HandleDOMEvent involving document.write to frameset → [FIXr]crash in GlobalWindowImpl::HandleDOMEvent involving document.write to frameset
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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.

Attachment

General

Creator:
Created:
Updated:
Size: