28548 - Crash on switching to another window while viewing page

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Sean Richardson]

Split off from bug 28356, "Extra space around navigation buttons, top of page"

At any time while the page at http://www.yodlee.com/ is visible, switching
away from the Mozilla window in which it is displayed results in an immediate
crash. Crash does not happen if another page at the site is displayed.
HTML Tidy complains, and the stylesheet does not seem to work properly for at
least some of the nav buttons at the top of the page, but Mozilla really should 
grin and bear it, not crash ;-)

Steps to Reproduce:
1. Load http://www.yodlee.com/ in Mozilla
2. Explore the site if you want, but return to the URL before continuing.
3. Switch to any other active window by ALT-TAB, taskbar, or mousing.

Actual Results:
Immediate and total crash of Mozilla, taking down all open windows, even
if the window switched to is another Mozilla window.

Expected Results:
Nothing of the sort.

Tested With:
2000-02-18-09-M14 nightly binary on Windows NT 4.0

No clue what component should catch this... but HTML Tidy prunes quite a few
start tags that don't belong where they are, and then complains when the end
tags appear, so perhaps the DOM Mozilla builds is fragile. Also, clicking on
the "Company" Nav button messes up, so the CSS might equally be flummoxing the
parser.

Comment 1

[Daniel Bratell]

Stack trace with event handling in the top. Reassigning to Event people.

nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x041d7d58, 
nsIPresContext * 0x02b03c78, nsGUIEvent * 0x0012fa50, nsIFrame * 0x03c81350, 
nsEventStatus * 0x0012f9b8, nsIView * 0x0233cb78) line 621 + 36 bytes
PresShell::HandleEvent(PresShell * const 0x03135a6c, nsIView * 0x0233cb78, 
nsGUIEvent * 0x0012fa50, nsEventStatus * 0x0012f9b8) line 2929 + 43 bytes
nsView::HandleEvent(nsView * const 0x0233cb78, nsGUIEvent * 0x0012fa50, unsigned 
int 8, nsEventStatus * 0x0012f9b8, int & 0) line 799
nsView::HandleEvent(nsView * const 0x00ed2f70, nsGUIEvent * 0x0012fa50, unsigned 
int 8, nsEventStatus * 0x0012f9b8, int & 0) line 784
nsView::HandleEvent(nsView * const 0x03135590, nsGUIEvent * 0x0012fa50, unsigned 
int 28, nsEventStatus * 0x0012f9b8, int & 0) line 784
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x03135340, nsGUIEvent * 
0x0012fa50, nsEventStatus * 0x0012f9b8) line 1216
HandleEvent(nsGUIEvent * 0x0012fa50) line 69
nsWindow::DispatchEvent(nsWindow * const 0x00ed302c, nsGUIEvent * 0x0012fa50, 
nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fa50) line 514
nsWindow::DispatchFocus(unsigned int 107) line 3084 + 15 bytes
nsWindow::ProcessMessage(unsigned int 8, unsigned int 0, long 0, long * 
0x0012fca4) line 2343 + 19 bytes
nsWindow::WindowProc(HWND__ * 0x00580878, unsigned int 8, unsigned int 0, long 
0) line 671 + 27 bytes
USER32! 77e13eb0()
USER32! 77e1591b()
USER32! 77e1595d()
NTDLL! 77f9fb83()
USER32! 77e191df()
nsAppShell::Run(nsAppShell * const 0x00e75aa8) line 96 + 24 bytes
nsAppShellService::Run(nsAppShellService * const 0x00e40f70) line 401
main1(int 1, char * * 0x00b76d18, nsISplashScreen * 0x00000000) line 651 + 32 
bytes
main(int 1, char * * 0x00b76d18) line 770 + 17 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()

Comment 2

[Richard Zach]

Doesn't happen on Linux.  Marking pp.

Comment 3

[ekrock's old account (dead)]

Reproduced using Commercial 3/3 on WinNT 4.0 SP4. Marking crash and M17.

Comment 4

[joki (gone)]

Cool.  We crash here while processing NS_DEACTIVATE

 // fire blur on document and window
 nsCOMPtr<nsIScriptGlobalObject> globalObject;

 gLastFocusedDocument->GetScriptGlobalObject(getter_AddRefs(globalObject));

because gLastFocusedDocument is null.  This is saari's stuff, reassigning to 
him.

Comment 5

[Pierre Saslawsky]

I can't reproduce the bug on WinNT and Mac, which is weird because the other 
persons had no problem reproducing it. I tested with a daily build from 03/05 and 
03/13 on WinNT and with the tips on the Mac.

saari: in case you can't reproduce it either, I hope the hint from joki will 
allow you to fix anyway.

Comment 6

[saari (gone)]

I can see, sort of where we would crash at the points Joki described. I can add 
in saftey checks, at the very least, and see where we crash next ;-)

Comment 7

[saari (gone)]

Added in saftey checks, cannot reproduce, marking fixed

Comment 8

[Jan Carpenter]

verified 
2000-05-09-09-M16