154191 - [FIX]Zombie windows prevent normal close of last window

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Peter Trudelle]

Using the 6/21 NS verification build, I just got into a state where closing the
last window would not trigger the normal app close behavior, in this case a
QuickLaunch 'exit'/restart.  After closing the last window, there was no
indication of any open window, not even in the Windows taskbar, yet the QL icon
remained, there was no disk activity associated with QL relaunch, and on
subsequent launch of mail I was able to use my account without authenticating. I
did notice that there were two blank entries in the Window menu list, but
selecting them did not change the active window, nor was there any sign of them
on the screen.  I was able to get a normal exit using File->Exit.

I don't know how to reproduce these invisible windows, but it seems that they
should not prevent normal close behavior, since users have no knowledge of them,
nor any way to close them, and expect that their mail account is not left open
for anyone to use after the last visible window is closed.

Comment 1

[Stephen P. Morse]

Peter, I have seen similar behavior with N4 occasionally (albeit very 
infrequently).  I would close down the last window, then relaunch and not get 
the splash screen but rather go right to the main window.  From the task manager 
I discovered that there was a zombie process of netscape.exe running.  I had to 
manually kill that process from the task manager.

I don't know what causes the machine to get into such a state, but I don't 
believe it is the fault of the browser (or any other application).  More likely 
some sort of glitch in the operating system.

Comment 2

[Peter Trudelle]

That doesn't sound like what I reported, which seemed pretty clear was two
windows known to the application but invisible to the user except in the Window
menu.  It may not be high impact, but I don't think we can just write it off as
an OS problem.

Comment 3

[Peter Trudelle]

I just had this happen again, with one zombie window in the menu.

Comment 4

[Peter Trudelle]

These zombie windows appear to be created when I try to print mail messages, as
reported in bug 151902.

Comment 5

[Peter Trudelle]

Once I set the proper prefs, I get this error on the JS console:
Error: window.arguments[3] has no properties
Source File: chrome://messenger/content/msgPrintEngine.js
Line: 64

Comment 6

[timeless]

um, that code just looks broken.

http://www.webreference.com/js/column79/7.html suggests an instanceOf function 
in case you need one, however not checking that arguments[3] is at least not 
null is pretty bad.

Comment 7

[rods (gone)]

Attachment: patch

not sure if this fixes the zombie windows, but it is needed anyway

Comment 8

[Jean-Francois Ducarroz]

Comment on attachment 89929 [details] [diff] [review]
patch

R=ducarroz

Comment 9

[(not reading, please use [e-mail] instead)]

Comment on attachment 89929 [details] [diff] [review]
patch

sr=sspitzer

Comment 10

[rods (gone)]

not sure if this is al that is needed to fix it, marking fixed, reopen if necessary