Closed Bug 307563 Opened 19 years ago Closed 19 years ago

download windows remain in "zombie" status after opening

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: emaijala+moz)

References

(
URL
)

Details

(Keywords: regression, verified1.8, Whiteboard: Also see bug 306925 and bug 307194)

Attachments

(2 files, 1 obsolete file)

example of the bug
(deleted), image/png
Details
Patch v1.1
(deleted), patch
roc
: review+
roc
: superreview+
asa
: approval1.8rc1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050908 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050908 SeaMonkey/1.1a

When you're using the music preview function and open a few of the links and not
only one, the download windows sometimes keep being shown after a click on OK.

Reproducible: Sometimes

Steps to Reproduce:
1. Go to the URL.
2. Click on some of the music preview links (called Hörbeispiele in german). A
window should open asking you, what to do with the file (I haven't found a
definite count for open windows until the bug appears, but the first column with
seven songs should work).
3. Select open and click on OK.

Actual Results:  
The file opens, but the download window remains with no content and only it's
titlebar (like "zombies").

Expected Results:  
Download window should be closed after click on ok.

I also encountered that problem with the profile manager and the preference
toolbar. The bug occurs from time to time since I'm using SeaMonkey nightlies
(beginning of august), but seems to get worse. I have to quit SeaMonkey to get
all of the zombie windows being closed.
Attached image example of the bug (deleted) — 
Watch the windows in the taskbar. They are all useless like the two shown
(title "Opening 01.04.rm" and "Opening 01.07.rm").
Correction to my initial posting. I typed preference toolbar, but meant the
normal preference window. There were no extensions installed and the profile was
new.
This is just like the symptoms of bug 304680, except that for a little while it
_seemed_ better, but now I'm seeing it all the time.
I can reproduce the bug with an unofficial branch build from
http://www.jonagold.org/seamonkey/2005-09-08-13-1.8/ (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 SeaMonkey/1.0a).

When offical branch builds are available, I'll test them too.

Marking the bug as possible blocker for seamonkey 1.0a
Version: unspecified → Trunk
Seems I don't have to rights to choose ? in the blocking-seamonkey1.0a field.

(In reply to comment #3)
The symptoms are definitely the same, maybe the two bugs have the same reason.
There are now 2 other bugs involving different modal+dialog windows like this
bug and displaying the same visual symptoms:
bug 306925 and bug 307194. The attachment 195316 [details] shows that the download window
does not close as it should.
Whiteboard: Also see bug 306925 and bug 307194
(In reply to comment #6)
I've seen these two bugs too, but was not able to reproduce it on my own.

So now we have at least 4 bugs with that problem bug 304680, bug 306925, bug
307194 and bug 307563.
< samuelsidler|work> If someone CCs me, I'll check on Mac when I get home.
Tried in a Mac branch nightly and couldn't reproduce.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050907
SeaMonkey/1.0a
Couldn't reproduce it with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1)
Gecko/20050908 SeaMonkey/1.1a

I reproduced it with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050908 SeaMonkey/1.1a on my second Windows XP SP2 Home but was not able
to reproduce it on a Windows XP SP2 Pro system (the same SeaMonkey build).

Perhaps it's only a problem with Windows XP SP2 Home?
Seeing it on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050908 SeaMonkey/1.0a (todays branch build) too.
Version: Trunk → 1.8 Branch
Depends on: 306925
This is a regression between Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9a1) Gecko/20050813 SeaMonkey/1.1a and Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.9a1) Gecko/20050814 SeaMonkey/1.1a

Gecko/20050814 is the first build I can reproduce this bug.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-13+06%3A00%3A00&maxdate=2005-08-14+06%3A00%3A00&cvsroot=%2Fcvsroot
Keywords: regression
Can everyone who sees this bug reproduce it as follows?

1. Load http://entropymine.com/jason/testbed/mime/
2. Click on the hilighted "file.foo" type at the bottom of the table
3. Don't do anything with the dialog--yet.  Click on the page, to draw focus away.
4. Click the Cancel button on the dialog, now.  Note that it sticks.
(In reply to comment #14)
> Can everyone who sees this bug reproduce it as follows?
> 
> 1. Load http://entropymine.com/jason/testbed/mime/
> 2. Click on the hilighted "file.foo" type at the bottom of the table
> 3. Don't do anything with the dialog--yet.  Click on the page, to draw focus away.
> 4. Click the Cancel button on the dialog, now.  Note that it sticks.

One minor, yet crucial addition to the above steps:

For step 2, spawn 2 or more dialog windows and then un-focus them (but don't
minimize them), then come back to step 4 for either of them, and you should see
this bug.
Well, everything points to bug 297561 as the cause for this problem. I just
can't figure out why it would cause this. I'll try to reproduce and debug.
(In reply to comment #14)
It's even easier at my system. I only have to click on file.foo and on cancel
afterwards to see the bug.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050910
SeaMonkey/1.0a
I can't reproduce this.

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050909 SeaMonkey/1.0a
Flags: blocking-seamonkey1.0a?
This only appears in edge cases and is seemingly hard to reproduce, and noone
has a clue yet why it happens. As Alpha is only a testing release, we can live
with it, and as we want to ship it _very_ soon, we can't wait for this I suppose.
Because of that this doesn't block Alpha. Everything might be different for Beta
though, once we have nmore investigation on what's happening here...
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
I can reproduce this on Windows XP SP2 with SeaMonkey 1.0a by going to
http://www.labhut.com/downloads/videos/index.php and clicking one of the
download links. The dialog that asks "What should SeaMonkey do with this file?"
often becomes a "zombie" after I click OK or Cancel.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-seamonkey1.0b?
(In reply to comment #19)
> This only appears in edge cases and is seemingly hard to reproduce, and noone
> has a clue yet why it happens. As Alpha is only a testing release, we can live
> with it, and as we want to ship it _very_ soon, we can't wait for this I suppose.
> Because of that this doesn't block Alpha. Everything might be different for Beta
> though, once we have nmore investigation on what's happening here...
I have been seeing this bug for 10 weeks on the
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/1.0a/
seamonkey-1.0a.en-US.linux-i686-gtk1.tar.gz builds. See the screeny
here: http://img300.imageshack.us/my.php?image=seamonkeybug0hy.jpg
This isnt an edge case, its easy to reproduce, another forum member
duped it on Debian Linux using the same Seamonkey gtk1 build I did.
http://forums.mozillazine.org/viewtopic.php?p=1750066#1750066
Screenies are Seamonkey Linux gtk1 9-17-2005 builds from above link.
Amber - Äkiidoll on MozForums


Uh oh, that makes the theory of the patch for bug 297561 being the culprit fail.
A new theory: this is something that the patch for bug 297561 caused to surface
on Win32 too.
inconnu on the MozForums writes: 
http://forums.mozillazine.org/viewtopic.php?p=1752228#1752228

I can duplicate on a 1.1a gtk1 build also.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050918 SeaMonkey/1.1a

No extensions, new profile; 5 out of 5:

http://tinypic.com/drfbdv.png

http://tinypic.com/drfbja.png

http://tinypic.com/drfbld.png

http://tinypic.com/drfbpe.png

http://tinypic.com/drfbrb.png

When I click the titlebar to focus the "Enter name of file to save to ..."
dialogue, the "Opening ..." dialogue closes, but not before.

Files are downloaded okay.
Can you someone please file a new bug on this issue (the Linux/GTK people)? I
think we should split this one off, since this is a second issue which should be
triaged in a new bug. It would help if you could find a regression range for the
bug you see, so someone with some bandwidth and a bit of time should download
builds from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/ and see
where this bug first started to occour.
Blocks: 309204
*** Bug 309204 has been marked as a duplicate of this bug. ***
I filed a new bug for the Seamonkey 1.0a/1.1a Linux gtk1 builds.
https://bugzilla.mozilla.org/show_bug.cgi?id=309414
No one is working on it/still flagged unconfirmed, has 1 vote so far beside my
filing. Can some one be assigned this bug? This is my first filing, so please
bare with me.
*** Bug 309414 has been marked as a duplicate of this bug. ***
Ere: Were you able to reproduce this, it seems the Linux problem was false
alarm? I would really like _not_ to see this bug in SeaMonkey 1.0 and Firefox
1.5 ;-).
I've been able to reproduce this quite well now and I've also been able to dig
out something possibly useful (needs still more investigation). It seems that
mouse trailer does something that sometimes causes a refcount problem for
nsWindow preventing it from being destroyed.
Assignee: guifeatures → emaijala
Attached patch Patch v1 (obsolete) (deleted) — — Splinter Review 
D'oh, now I feel stupid. The new mouse trailer stuff had a serious ref leak
right under my nose. Namely, nsWindow::GetTopLevelWindow() of course addrefs
the pointer but mouse trailer fails to release it.
Attachment #199580 - Flags: superreview?(roc)
Attachment #199580 - Flags: review?(roc)
Attachment #199580 - Flags: approval1.8rc1?
*** Bug 306925 has been marked as a duplicate of this bug. ***
Blocks: 304680
*** Bug 307194 has been marked as a duplicate of this bug. ***
Attached patch Patch v1.1 (deleted) — — Splinter Review 
Removed the extra nullifications which NS_IF_RELEASE already does for us.
Attachment #199580 - Attachment is obsolete: true
Attachment #199586 - Flags: superreview?(roc)
Attachment #199586 - Flags: review?(roc)
Attachment #199586 - Flags: approval1.8rc1?
Attachment #199580 - Flags: superreview?(roc)
Attachment #199580 - Flags: review?(roc)
Attachment #199580 - Flags: approval1.8rc1?
Comment on attachment 199586 [details] [diff] [review]
Patch v1.1

Please request approval after this has been fully reviewed, landed, and
verified on the trunk. Thanks.
Attachment #199586 - Flags: approval1.8rc1?
Blocks: 307194
Component: XP Apps: GUI Features → Widget: Win32
Flags: blocking-seamonkey1.0b?
Flags: blocking-seamonkey1.0a-
Product: Mozilla Application Suite → Core
QA Contact: ian
Version: 1.8 Branch → Trunk
Comment on attachment 199586 [details] [diff] [review]
Patch v1.1

I guess we got used to using nsCOMPtrs.

Actually is there some reason why we can't use nsCOMPtr here?
Attachment #199586 - Flags: superreview?(roc)
Attachment #199586 - Flags: superreview+
Attachment #199586 - Flags: review?(roc)
Attachment #199586 - Flags: review+
I tried but nsCOMPtr doesn't seem to like the forward declaration of nsWindow. I
also tested nsRefPtr, but it seems to depend on nsCOMPtr and didn't work either.
Checked in to trunk.
Maybe we can move the declaration of MouseTrailer to somewhere where we can
include nsWindow.h before it? Something to think about for trunk, anyway.
Comment on attachment 199586 [details] [diff] [review]
Patch v1.1

We really need this fix for 1.5. Apart from fixing a huge resource leak, it's
also fixing hard-to-reproduce but highly visible Windows bugs.
Attachment #199586 - Flags: approval1.8rc1?
Attachment #199586 - Flags: approval1.8rc1? → approval1.8rc1+
Checked in to branch. Verification of the fix would be appreciated.

I filed bug 312566 for moving MouseTrailer away from nsToolkit.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.8rc1+
(In reply to comment #40)
> Checked in to branch. Verification of the fix would be appreciated.
> 
> I filed bug 312566 for moving MouseTrailer away from nsToolkit.

I'll verify this as soon as win32 builds are back on ftp.mozilla.org, which
should be this Monday.
Blocks: 306925
No longer depends on: 306925
Works fine with Gecko/20051016 SeaMonkey/1.0b so far. Wasn't able to reproduce
it with any of the test cases. Tanks for your work Ere!
adding the fixed1.8 keyword since this bug was fixed on the branch several days ago.
Keywords: fixed1.8
Keywords: fixed1.8 → verified1.8
Verified FIXED using SeaMonkey 1.1a;Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.9a1) Gecko/20051020 SeaMonkey/1.1a on
http://entropymine.com/jason/testbed/mime/.

I multi-stacked windows on top of each other, minimized and then un-minimized
from the taskbar, etc., with no observable "zombie" behavior.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: