138349 - Distorted print preview on my.yahoo.com

Status: VERIFIED FIXED

(Core :: Print Preview, defect, P2)

Description

[Moied]

User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) 
Build Gecko/20020418 Netscape6/6.2.1+ 
OS : WINXP

Distorted print preview seen on my.yahoo.com there is extra white spaces all
over the right side of the page

Steps to reproduce :
go to my.yahoo.com.
file| print preview 
scroll down this document 
Observe white space allover right hand side of the page.

Screen shot fallows..

Comment 1

[Moied]

Attachment: Distorted print preview images

Comment 2

[Matthias Versen [:Matti]]

-> Print preview

Comment 3

[sujay]

confirming.....page is all screwed up in PP mode.
whitespace on right side everywhere.

Comment 4

[rods (gone)]

need a tescase, I don't have a yahoo sign in, please un future when testcase is
available

Comment 5

[Andrew Hagen]

Not screwed up in Mozilla 1.1 alpha Build ID: 2002060704, Windows 98. But when
you exit print preview of http://my.yahoo.com, Mozilla crashes.

Comment 6

[Paul Gregg]

Attachment: my yahoo testcase

Comment 7

[Paul Gregg]

WFM  Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020703  SP6a
I too can confirm it doesn't distort PP

But it did crash for me as well, so I experimented...
* TB8200365Y - clicking on close button on toolbar --> BOOM
* TB8200630Q - goto PP -> page setup -> click "print background" -> click ok
button  --> BOOM
* TB8200757W - completely signed out (so normal my.yahoo page for non-yahoo
people), clicked PP in File menu --> BOOM
* TB8200779E - as 757W above  ^^^^^^^
* TB8200881M - as above, but with the my.yaoo.com page saved to disk  (attached
above - attachment 90915 [details] )

Not sure whether to remove qawanted or testcase so leaving.
Would you like the testcase reduced???
Can't change future milestone either.....
Also, I guess its not just WindowsXP, maybe all windows machines

Comment 8

[rods (gone)]

crash  in the destroying of frames it looks like it is in the text field

Comment 9

[rods (gone)]

Attachment: stack trace

Comment 10

[kinmoz]

Attachment: Testcase with fewer widgets

This version of the testcase loads into print preview, but crashes when you
close the window with the same stack reported earlier except that the frame
involved is the combobox's nsListControlFrame.

The crash is due to the fact that we are blowing away the view for the
ViewPort, which in turn blows away all it's child views. When we get around to
blowing away the ViewPort's child frames, all of their views (stored in the
FrameManager) have been blown away already, so when they want to null out their
view's client data pointer, the view pointer they get back from the frame
manager is non-null and pointing to garbage.

I'm not exactly sure why this crash doesn't happen if I remove some of the
contents of the tables in the test case.

Note that the crash stack in this bug is one of the stacks reported in bug
156982.

Here's the stack that shows how the ViewPort triggers the view for the
nsListControlFrame.

nsView::~nsView() line 102
nsScrollingView::~nsScrollingView() line 423 + 22 bytes
nsScrollingView::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsView::Destroy(nsView * const 0x03af38d0) line 260 + 34 bytes
nsView::~nsView() line 109
nsView::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsView::Destroy(nsView * const 0x03aca5d8) line 260 + 34 bytes
nsFrame::Destroy(nsFrame * const 0x03aca9fc, nsIPresContext * 0x03acf988) line
484
nsContainerFrame::Destroy(nsContainerFrame * const 0x03aca9fc, nsIPresContext *
0x03acf988) line 144
ViewportFrame::Destroy(ViewportFrame * const 0x03aca9fc, nsIPresContext *
0x03acf988) line 154
FrameManager::Destroy(FrameManager * const 0x03aca348) line 504
PresShell::Destroy(PresShell * const 0x03ad0a60) line 1890
DocumentViewerImpl::ReturnToGalleyPresentation() line 6111
DocumentViewerImpl::ExitPrintPreview(DocumentViewerImpl * const 0x039b1548)
line 5914
XPTC_InvokeByIndex(nsISupports * 0x039b1548, unsigned int 18, unsigned int 0,
nsXPTCVariant * 0x0012d840) line 106
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 1994 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x01bdb9d0, JSObject * 0x01aeaf58, unsigned int
0, long * 0x03b3747c, long * 0x0012db1c) line 1266 + 14 bytes
js_Invoke(JSContext * 0x01bdb9d0, unsigned int 0, unsigned int 0) line 788 + 23
bytes
js_Interpret(JSContext * 0x01bdb9d0, long * 0x0012e95c) line 2743 + 15 bytes
js_Invoke(JSContext * 0x01bdb9d0, unsigned int 1, unsigned int 2) line 805 + 13
bytes
js_InternalInvoke(JSContext * 0x01bdb9d0, JSObject * 0x014eef88, long 28555472,
unsigned int 0, unsigned int 1, long * 0x0012ebb4, long * 0x0012ea84) line 880
+ 20 bytes
JS_CallFunctionValue(JSContext * 0x01bdb9d0, JSObject * 0x014eef88, long
28555472, unsigned int 1, long * 0x0012ebb4, long * 0x0012ea84) line 3428 + 31
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x030bf028, void *
0x014eef88, void * 0x01b3b8d0, unsigned int 1, void * 0x0012ebb4, int *
0x0012ebb8, int 0) line 1042 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03a9a130,
nsIDOMEvent * 0x03abb158) line 182 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03a52be0,
nsIDOMEvent * 0x03abb158, nsIDOMEventTarget * 0x03109af0, unsigned int 2,
unsigned int 7) line 1221 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x032f9a08,
nsIPresContext * 0x032ff828, nsEvent * 0x0012f394, nsIDOMEvent * * 0x0012f310,
nsIDOMEventTarget * 0x03109af0, unsigned int 7, nsEventStatus * 0x0012f3dc)
line 2218 + 36 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x03109ae0,
nsIPresContext * 0x032ff828, nsEvent * 0x0012f394, nsIDOMEvent * * 0x0012f310,
unsigned int 1, nsEventStatus * 0x0012f3dc) line 763
nsWebShellWindow::ExecuteCloseHandler() line 1511 + 53 bytes
nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012f58c) line 484 + 8 bytes
nsWindow::DispatchEvent(nsWindow * const 0x0316aca4, nsGUIEvent * 0x0012f58c,
nsEventStatus & nsEventStatus_eIgnore) line 1034 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f58c) line 1055
nsWindow::DispatchStandardEvent(unsigned int 101) line 1075 + 15 bytes
nsWindow::ProcessMessage(unsigned int 16, unsigned int 0, long 0, long *
0x0012f984) line 3633
nsWindow::WindowProc(HWND__ * 0x005204ca, unsigned int 16, unsigned int 0, long
0) line 1303 + 27 bytes
USER32! 77e11b60()
USER32! 77e12f29()
USER32! 77e12f4f()
NTDLL! 77fa032f()
USER32! 77e14c17()
USER32! 77e11b60()
USER32! 77e142eb()
USER32! 77e14ce5()
nsWindow::WindowProc(HWND__ * 0x005204ca, unsigned int 274, unsigned int 61536,
long 1573566) line 1314 + 31 bytes
USER32! 77e11b60()
USER32! 77e12f29()
USER32! 77e12f4f()
NTDLL! 77fa032f()
USER32! 77e14c17()
USER32! 77e11b60()
USER32! 77e142eb()
USER32! 77e14ce5()
nsWindow::WindowProc(HWND__ * 0x005204ca, unsigned int 161, unsigned int 20,
long 1573566) line 1314 + 31 bytes
USER32! 77e11b60()
USER32! 77e11cca()
USER32! 77e183f1()
nsAppShellService::Run(nsAppShellService * const 0x014f5a68) line 452
main1(int 2, char * * 0x003074c8, nsISupports * 0x00000000) line 1456 + 32
bytes
main(int 2, char * * 0x003074c8) line 1805 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8d326()

Comment 11

[kinmoz]

So apparently when the the viewports->Destroy() method is called, we aren't
blowing away all the child frames we should be when it invokes
mFrames.DestroyFrames() in nsContainerFrame::Destroy().  This allows some of the
child frames to exist at the time the viewport's view is destroyed.

The child frames with views that should've been destroyed are then free'd as the
result of the FrameManager running through and freeing all of it's properties.

Comment 12

[kinmoz]

Attachment: Small Testcase

Got the testcase down to something manageable. It looks like we aren't freeing
the floating table when destroying page 2's floater list for body.

Comment 13

[kinmoz]

The fix for bug 153785 prevents all of the attached test cases from crashing.

Comment 14

[karnaze (gone)]

The patch for bug 153785 is in the trunk.

Comment 15

[Greg K.]

Verified with Win FF 1.5.