Closed Bug 309414 Opened 19 years ago Closed 19 years ago

download windows remain in "zombie" status after opening

Categories

(SeaMonkey :: UI Design, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 280518

People

(Reporter: kost1903, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.11) Gecko/20050729 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a1) Gecko/20050920 SeaMonkey/1.1a Seamonkey gtk1 bulds. Here is what I see when I click a file link to save >then try to save the file >as you see the front box doesnt go away like it should, it stays in front of the other dialog box after clicking the OK button. http://img300.imageshack.us/my.php?image=seamonkeybug0hy.jpg http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-07-03-06-trunk/ Is as far back as I can find the bug. Now the Linux gtk1 20-Sep-2005 from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ is also broke in the download manager 'save as' dialog box acting zombie, this build is missing the buttons comepletely. http://img293.imageshack.us/my.php?image=sm920nightly2rv.jpg. Per recommendation from Frank Wein: 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. Reproducible: Always Expected Results: The initial 'save as' dialog box should go away after clicking a button, but it launches the second 'save too pathway' dialog box as it but stays in 'zombie' in front.
I've reproduced this bug on the gtk1 SeaMonkey builds I've tested. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050703 SeaMonkey/1.0a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050918 SeaMonkey/1.1a OS: Debian GNU/Linux 3.1 Representative screenshot from test of Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050918 SeaMonkey/1.1a: http://tinypic.com/drfbld.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.
*** This bug has been marked as a duplicate of 307563 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
err, can you move the "zombie" dialog or minimize it?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Just tried the gtk1 comet-trunk, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050921 SeaMonkey/1.1a, and yes, I could both move and minimise the "zombie" dialogue.
Before I filed this, Inconnu confirmed the bug too on a 32bit chipset. My reasoning was I had run into this bug for weeks on end, but chipset architecture Im using is AMD64 3400+ on SuSE 9.2 Pro. Inconnu is using a 32bit chipset, that verified the bug isnt 64bit specific on Linux gtk1 builds. Plus the fact that Frank Wein wanted a seperate filing specific to SeaMonkey 1.0a/1.1a Linux gtk1.
Before I filed this, Inconnu confirmed the bug too on a 32bit chipset. My reasoning was I had run into this bug for weeks on end, but chipset architecture Im using is AMD64 3400+ on SuSE 9.2 Pro. Inconnu is using a 32bit chipset, that verified the bug isnt 64bit specific on Linux gtk1 builds. Plus the fact that Frank Wein wanted a seperate filing specific to SeaMonkey 1.0a/1.1a Linux gtk1. I can always focus on the back dialogue box and/or minimize the 'zombie'.
> I can always focus on the back dialogue box and/or minimize the 'zombie'. and the dialog retains its content when you do that? The description in bug 307563 is that the content is no longer drawn once the bug hits. It sounds like you're seeing bug 280518.
Thank you for pointing out Bug 280518; that seems closer. Yes, the dialogue retains content after moving/resizing. It's possible to select another option, "Open with ...", change one's mind, and then select save to disc again, in which case a second "Enter name of file" dialogue is created. Screen capture from Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050918 SeaMonkey/1.1a gtk1 using KDE 3.3.2 on Debian 3.1 stable: http://tinypic.com/dxbxu0.png I noticed essentially the same behaviour when re-testing Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050703 SeaMonkey/1.0a gtk1. At this point, further interaction was possible with the "Enter name ... " dialogues. However, though I could change download directory, create a new folder, change the name of the file, and click the "Save" button (thus closing the dialogue), files weren't saved (with either of 2 "Enter name ..." dialogues). Files are saved if one doesn't interact with the "Opening ... " (zombie) dialogue after clicking "OK" the first time. On further investigation, the "zombie dialogue" isn't closed on clicking the titlebar of the "Enter name of file ... " dialogue; it loses focus and is behind other SeaMonkey windows. It will still accept input if brought to the front. After cancelling all "Enter name ..." dialogues, the "Saving ... " dialogue closes.
Are you using KDE?
Yes, KDE 3.3.2 on Debian 3.1 (stable), kernel 2.6.8-2-386
Version: unspecified → Trunk
Yes KDE 3.3.0 - SuSE Linux 9.2 Pro - kernel 2.6.8-24 - machine x86_64 I see the same exact behaviour Inonnu described.
ok, then it's definitely bug 280518 *** This bug has been marked as a duplicate of 280518 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → DUPLICATE
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.