Closed
Bug 309414
Opened 19 years ago
Closed 19 years ago
download windows remain in "zombie" status after opening
Categories
(SeaMonkey :: UI Design, defect)
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.
Comment 2•19 years ago
|
||
*** This bug has been marked as a duplicate of 307563 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Comment 3•19 years ago
|
||
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'.
Comment 7•19 years ago
|
||
> 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.
Comment 9•19 years ago
|
||
Are you using KDE?
Comment 10•19 years ago
|
||
Yes, KDE 3.3.2 on Debian 3.1 (stable), kernel 2.6.8-2-386
Reporter | ||
Comment 11•19 years ago
|
||
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.
Comment 12•19 years ago
|
||
ok, then it's definitely bug 280518
*** This bug has been marked as a duplicate of 280518 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•