Closed Bug 284579 Opened 19 years ago Closed 19 years ago

Download-dialog's OK-button is disabled it the window isn't active

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: taboom, Assigned: bugs)

References

Details

(Whiteboard: as-designed to combat bug 260560) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Tro to open a file (say a zip) and Firefox asks "Opening a.zip" and you can Open
with (program) or "save to disk". Now if you don't select anything, but continue
surfing (focus the main window), the download-dialog stays on top, grayed out,
but so is also the OK-button, but not the Cancel button. Clicking on the window
gives it focus, and the OK-button comes available again. I believe the OK-button
should stay (as the cancel button also) possible to click even if the window
isn't focused. Now you might have to ckick twise on the ok-button to start the
download (once to focus the window, and then again to click ok)

Reproducible: Always

Steps to Reproduce:
1. try to start download (click a zip-file), make sure Firefox asks what to do
witht eh file
2. focus the main window (not the download dialog)


Actual Results:  
ok-button is grayed out

Expected Results:  
ok button is possible to click, as the calcel button also is
Confirming with Firefox Trunk Nightly on Windows (Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050303 Firefox/1.0+) and on Firefox
1.0.1 Release.

Not sure if this is intended behavior though, but in any case it is inconsistent
with what the Cancel button does.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's intentional that the OK button is disabled when the window doesn't have
focus (see bug 260560).  Why it the dialog in front even thought it doesn't have
focus?
Could be the window focus policy settings.  I run KDE 3.2 on SuSE 9.1 and have
the focus prevention turned way up high because too many programs (including
Firefox/Thunderbird/Mozilla) have been abusing focus-stealing.  Unfortunately,
this results in a lot of unfocused windows that should be focused.  It's kind of
annoying, but not as annoying as the windows actually taking focus when it
shouldn't (for me).
When click on "choose application with" radiobutton and than back to save radio
button, the OK Button will became active !
 
*** Bug 312758 has been marked as a duplicate of this bug. ***
*** Bug 316108 has been marked as a duplicate of this bug. ***
I would like this fixed.
Invalid (see comment 2).  File a new bug report for each bug that causes the download dialog to be in the background (or not have focus) when that shouldn't happen.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
This happens every time. Not just on a few downloads, every time!(In reply to comment #8)
> Invalid (see comment 2).  File a new bug report for each bug that causes the
> download dialog to be in the background (or not have focus) when that shouldn't
> happen.
> 

New bug is not needed!

Zack, it may always happen for you, but it never happens for me, and the reasons it happens for other people might not be the same as the reason it happens for you.  That's why you should file a separate bug and try to figure out why it happens for you.
I reopened Zacks bug
This happens a lot...Have no idea why though.
Just confirming this with Firefox 1.0.5.0.1 on Debian (Debian/1.5.dfsg+1.5.0.1-2) and also on Windows 1.0.5.0.1
*** Bug 344815 has been marked as a duplicate of this bug. ***
*** Bug 344815 has been marked as a duplicate of this bug. ***
Can we reopen this bug and get an option to disable this behaviour?  The disabling of the OK button is completely useless in a focus follows mouse window manager.  In the unix world, you can't rely on everyone using a click to focus window manager.  For the rest of us, not only does this solution not work, it is unecessesary anyway, and only hinders normal operation.

Even on windows, you can force a status bar to be displayed, so you should at
least give the user an option to explicitly disable this "feature" if they are
capable of discerning a spoofed dialog from a real one.
*** Bug 352138 has been marked as a duplicate of this bug. ***
*** Bug 358869 has been marked as a duplicate of this bug. ***
*** Bug 360828 has been marked as a duplicate of this bug. ***
Its not resolved!
What kind of bug resolving in mozilla?
Bugs remains for ages and mark as resolved?!
OMG!
It's marked as "invalid", not as "fixed".  Don't let "resolved" mislead you, that just means the bug is no longer open.

Most of the bugs marked as dups of this one should not have been marked as dups of this one; see comment 2 and comment 8.  That includes any issues with the "focus-follows-mouse" paradigm, where it might make more sense to look at whether the window is obscured instead of whether it has focus.
Just two ideas to get the download window to behave more like users expect it to. Is it possible to (1) add a check if there is a firefox (or any) window on top of the download window and disable the OK button only if there is some reason for this. The reason for disabling the button is due to windows covering it and possibly fooling the user after all.

Alternatively (2) the download-window could me a modal dialog or otherwise impossible to cover with another window. This should be much easier to implement ,(right?) while still getting to a working solution. Now the button is disabled based on focus, when focus really isn't the real problem here.

This disabling of the download-button constantly annoys me when downloading files and I feel that technical decisions/difficulties to overcome this really shouldn't be the reason for making users have to stand up with this kind of behavior. 

(In reply to comment #21)

> Most of the bugs marked as dups of this one should not have been marked as dups
> of this one; see comment 2 and comment 8.  That includes any issues with the
> "focus-follows-mouse" paradigm, where it might make more sense to look at
> whether the window is obscured instead of whether it has focus.
>
This bug is very unclear to me and especially the reason why it is not fixed..
Always, when you click in Windows outside the dialog, the OK button becomes disabled. Although maybe logical, in practice this is useless behaviour. It adds nothing useful :).
The same happens when you are downloading more files from the same page and one download is finished. It tears away the focus of the dialog and disables the OK button.
If the OK button were always enabled, this would solve the problems. Although I don't know if it would be possible.
Should there be filed a new bug for this?
Whiteboard: as-designed to combat bug 260560
Is there any solution found for this problem?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.