271019 - Javascript+XUL: Calling print() on a reference to a no longer visible iframe crashes Firefox 1.0 on Win2K/SP4.

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Kevin Frost]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Given a reference to an iframe in an XUL document, calling print() on that
reference after making the iframe invisible causes a crash.

The iframe disappears from windows.frames when its enclosing box is no longer
displayed.  Trying to print it at that point crashes the client.

I have tested this *only* on Firefox 1.0 / Windows 2000 SP4, and only with the
print() method.  Sorry, have no more time to investigate at the moment.

Although it does cause a crash I don't think it's necessarily a critical bug,
since inducing the crash would require a malicious web page, and is not
something a user would encounter in normal operation of the browser.  Anybody
trying to print in this circumstance in XUL/JS is going to note the problem and
find another way to print, I think.


Reproducible: Always
Steps to Reproduce:
1. Load an XUL document with at least one iframe, enclosed in a box.
2. In Javascript, make a variable refer to that iframe.
3. Make the enclosing box invisible.
  ( - now the iframe is no longer part of window.frames, alas!)
4. whateverVariableWasYourIframe.print();
5. Kablooie.

May affect other methods, I didn't investigate that far.  May also require some
content in the iframe.

Actual Results:  
Browser crashed, feedback agent launched.

Expected Results:  
It should have printed the iframe.


Sorry, will have to get back to you on that.  If I check it now I lose the rest
of  the entry ;-)

Comment 1

[timeless]

    NS_WARN_IF_FALSE(aIndex >=0 && aIndex < mChildren.Count(), "index of child
element is out of range!");
+	mChildren	{mImpl=0x05a29c78 {mBits=0x80000008 mCount=0x00000000
mArray=0x05a29c80 } }	nsVoidArray
	aIndex	0x00000000	int

 	xpcom_core.dll!nsDebug::Assertion(const char * aStr=0x019e1fc8, const char *
aExpr=0x019e1f9c, const char * aFile=0x019e1f74, int aLine=0x00000891)  Line 109	C++
 	docshell.dll!nsDocShell::GetChildAt(int aIndex=0x00000000, nsIDocShellTreeItem
* * aChild=0x0012d374)  Line 2193 + 0x34	C++
 	gklayout.dll!nsDOMWindowList::Item(unsigned int aIndex=0x00000000,
nsIDOMWindow * * aReturn=0x0012d3d0)  Line 140 + 0x2e	C++
 	gklayout.dll!nsWindowSH::GetProperty(nsIXPConnectWrappedNative *
wrapper=0x04b43e70, JSContext * cx=0x03ec1380, JSObject * obj=0x04b2df98, long
id=0x00000001, long * vp=0x0012dda4, int * _retval=0x0012d410)  Line 3650 + 0x35	C++
 	xpc3250.dll!XPC_WN_Helper_GetProperty(JSContext * cx=0x03ec1380, JSObject *
obj=0x04b2df98, long idval=0x00000001, long * vp=0x0012dda4)  Line 811 + 0x2f	C++
>	js3250.dll!js_GetProperty(JSContext * cx=0x03ec1380, JSObject *
obj=0x04b2df98, long id=0x00000001, long * vp=0x0012dda4)  Line 2635 + 0x13d	C
 	js3250.dll!js_Interpret(JSContext * cx=0x03ec1380, long * result=0x0012deec) 
Line 3462 + 0x6d6	C
 	js3250.dll!js_Invoke(JSContext * cx=0x03ec1380, unsigned int argc=0x00000000,
unsigned int flags=0x00000000)  Line 1306 + 0xd	C
 	js3250.dll!js_Interpret(JSContext * cx=0x03ec1380, long * result=0x0012e928) 
Line 3619 + 0xf	C
 	js3250.dll!js_Invoke(JSContext * cx=0x03ec1380, unsigned int argc=0x00000001,
unsigned int flags=0x00000002)  Line 1306 + 0xd	C
 	js3250.dll!js_InternalInvoke(JSContext * cx=0x03ec1380, JSObject *
obj=0x0555ff10, long fval=0x05206188, unsigned int flags=0x00000000, unsigned
int argc=0x00000001, long * argv=0x0012ec28, long * rval=0x0012ec2c)  Line
1383 + 0x14	C
 	js3250.dll!JS_CallFunctionValue(JSContext * cx=0x03ec1380, JSObject *
obj=0x0555ff10, long fval=0x05206188, unsigned int argc=0x00000001, long *
argv=0x0012ec28, long * rval=0x0012ec2c)  Line 3794 + 0x1f	C
 	gklayout.dll!nsJSContext::CallEventHandler(JSObject * aTarget=0x0555ff10,
JSObject * aHandler=0x05206188, unsigned int argc=0x00000001, long *
argv=0x0012ec28, long * rval=0x0012ec2c)  Line 1361 + 0x21	C++
 	gklayout.dll!nsJSEventListener::HandleEvent(nsIDOMEvent * aEvent=0x05421628) 
Line 205 + 0x2d	C++
 	gklayout.dll!nsEventListenerManager::HandleEventSubType(nsListenerStruct *
aListenerStruct=0x05979498, nsIDOMEvent * aDOMEvent=0x05421628,
nsIDOMEventTarget * aCurrentTarget=0x05865cf8, unsigned int aSubType=0x00000008,
unsigned int aPhaseFlags=0x00000007)  Line 1524 + 0x14	C++
 	gklayout.dll!nsEventListenerManager::HandleEvent(nsPresContext *
aPresContext=0x05887a20, nsEvent * aEvent=0x0012f1a8, nsIDOMEvent * *
aDOMEvent=0x0012f15c, nsIDOMEventTarget * aCurrentTarget=0x05865cf8, unsigned
int aFlags=0x00000007, nsEventStatus * aEventStatus=0x0012f1a4)  Line 1618	C++
 	gklayout.dll!nsXULElement::HandleDOMEvent(nsPresContext *
aPresContext=0x05887a20, nsEvent * aEvent=0x0012f1a8, nsIDOMEvent * *
aDOMEvent=0x0012f15c, unsigned int aFlags=0x00000007, nsEventStatus *
aEventStatus=0x0012f1a4)  Line 2820	C++
 	gklayout.dll!PresShell::HandleDOMEventWithTarget(nsIContent *
aTargetContent=0x05ac2788, nsEvent * aEvent=0x0012f1a8, nsEventStatus *
aStatus=0x0012f1a4)  Line 6038	C++
 	gklayout.dll!nsButtonBoxFrame::MouseClicked(nsPresContext *
aPresContext=0x05887a20, nsGUIEvent * aEvent=0x0012f65c)  Line 178	C++
 	gklayout.dll!nsButtonBoxFrame::HandleEvent(nsPresContext *
aPresContext=0x05887a20, nsGUIEvent * aEvent=0x0012f65c, nsEventStatus *
aEventStatus=0x0012f43c)  Line 124	C++
 	gklayout.dll!PresShell::HandleEventInternal(nsEvent * aEvent=0x0012f65c,
nsIView * aView=0x05a53d90, unsigned int aFlags=0x00000001, nsEventStatus *
aStatus=0x0012f43c)  Line 6003 + 0x27	C++
 	gklayout.dll!PresShell::HandleEvent(nsIView * aView=0x05a53d90, nsGUIEvent *
aEvent=0x0012f65c, nsEventStatus * aEventStatus=0x0012f43c, int
aForceHandle=0x00000001, int & aHandled=0x00000001)  Line 5814 + 0x19	C++
 	gklayout.dll!nsViewManager::HandleEvent(nsView * aView=0x05a53d90, nsGUIEvent
* aEvent=0x0012f65c, int aCaptured=0x00000000)  Line 2348	C++
 	gklayout.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent=0x0012f65c,
nsEventStatus * aStatus=0x0012f5a4)  Line 2121 + 0x14	C++
 	gklayout.dll!HandleEvent(nsGUIEvent * aEvent=0x0012f65c)  Line 166	C++
 	gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012f65c,
nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 1074 + 0xa	C++
 	gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0012f65c) 
Line 1095	C++
 	gkwidget.dll!nsWindow::DispatchKeyEvent(unsigned int aEventType=0x00000083,
unsigned short aCharCode=0x0000, unsigned int aVirtualCharCode=0x0000000d, long
aKeyData=0x001c0001)  Line 3003 + 0xf	C++
 	gkwidget.dll!nsWindow::OnKeyDown(unsigned int aVirtualKeyCode=0x0000000d,
unsigned int aScanCode=0x0000001c, long aKeyData=0x001c0001)  Line 3129	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=0x00000100, unsigned
int wParam=0x0000000d, long lParam=0x001c0001, long * aRetValue=0x0012fbb8) 
Line 3967 + 0x1d	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x04701330, unsigned int
msg=0x00000100, unsigned int wParam=0x0000000d, long lParam=0x001c0001)  Line
1355 + 0x1b	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!GetMessageW()  + 0x125	
 	user32.dll!DispatchMessageW()  + 0xb	
 	appcomps.dll!nsAppStartup::Run()  Line 216	C++
 	mozilla.exe!main1(int argc=0x00000001, char * * argv=0x00347b80, nsISupports *
nativeApp=0x012360a0)  Line 1321 + 0x20	C++
 	mozilla.exe!main(int argc=0x00000001, char * * argv=0x00347b80)  Line 1813 +
0x25	C++
 	mozilla.exe!mainCRTStartup()  Line 400 + 0x11	C
 	kernel32.dll!TermsrvAppInstallMode()  + 0x269

Comment 2

[timeless]

assert fired here:
	var thePrintFrame = window.frames[0];
	
	// the frame document object:
	var doc = thePrintFrame.document;
Error: thePrintFrame has no properties
Source File: http://www.betavote.com/xul-print-crash/xul-print-crash.js
Line: 9

Comment 3

[Boris Zbarsky [:bzbarsky]]

bsmedberg, this bug a problem in trunk builds?  In the only testcase I see in
this bug, a debug build tells me "the document was misplaced while you were
trying to print" and does NOT crash.

If this is only a problem on branch, why was it confirmed as a trunk bug, exactly?

As for the rest of comment 0, setting display:none on an iframe means that its
window object and rendering tree are destroyed.  Hence, there is nothing left to
print.  We shouldn't be crashing, but the "the document was misplaced" error
message that comes up is the one that should come up.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, and for _HTML_ frames and iframes the window/document don't die when display
is set to "none".  That part of this behavior is a special property of XUL
iframes.  So reassigning to the right component.

Comment 5

[Chris Cooper [:coop] (he/him)]

I am able to reproduce this crash on linux using a 1.0.4 release build, and a
1.0.5 candidate release build, but a version of Deer Park compiled yesterday
(2005/07/07) doesn't crash.

Here's the simple HTML I'm using to reproduce this:

<html>
<body>
<iframe id="pocframe" name="pocframe" src="about:blank"></iframe>
<script type="text/javascript">window.frames.pocframe.print();</script>
</body>
</html>

This code was provided by Nick here in the Quality blog:
http://weblogs.mozillazine.org/qa/archives/2005/07/some_stats.html

I've also made the test page available online here (warning: this may crash your
browser):
http://coop.deadsquid.com/test/iframe_crash.html

Builds affected:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.9) Gecko/20050707 Firefox/1.0.5

Builds not affected:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050707 Firefox/1.0+

Talkback Link (for 1.0.5 crash):
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=7327654

Comment 6

[Boris Zbarsky [:bzbarsky]]

See comment 3.  This has gotten fixed sometime since April 2004 (which is when
the Gecko 1.0.x Firefox builds are using dates from).

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> See comment 3.  This has gotten fixed sometime since April 2004 (which is when
> the Gecko 1.0.x Firefox builds are using dates from).

so there's no problem?  Or, it just doesn't crash?

Comment 8

[Joachim Rousseau]

I experienced a similary bug (se my comment bug#359119) with non-XUL app with Firefox 2.0, Win2k SP4 (classical HTML page with javascript). Firefox doesn't crash but stop to respond (0% CPU usage, clossing window does not shutdown process).

Comment 9

[Jesse Ruderman on Windows]

Sounds like this was already WFM-on-trunk a few years ago.