Closed Bug 346513 Opened 13 years ago Closed 12 years ago

option to disable 'OK button disabled when "Opening/Save to disk" dialog is not focussed'

Categories

(Toolkit :: Downloads API, defect)

1.8.0 Branch
x86
Linux
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 264492

People

(Reporter: tim.w.connors, Unassigned)

Details

User-Agent:       Opera/9.00 (X11; Linux i686; U; en)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060506 Firefox/1.5.0.4 (Debian-1.5.dfsg+1.5.0.4-3)

This is *not* a duplicate of bug 344815 or bug 260560, nor for the closed bug 284579 -- I'm asking for an option to disable this behaviour, rather than simply making it on for everyone.

Currently, the "ok" button in at least the "open or save to file" dialog (possibly more dialogs, this is the one that gets me all the time) is disabled when the window doesn't have focus, as per bug 260560.  The proper solution of course doesn't even belong in firefox -- it would be to implement a decent policy within the window manager (such as having a border all around the focussed window, and highlighting it), but I appreciate some popular window managers are broken in this regard, so having an disabled OK button may suit users of such.

For the rest of us, particularly those of us using focus-follows-window managers (and also, I hear, those who use window managers who deliberately design no correlation between the mouse cursor and focus, such that even clicking on a window will not give it focus, implying that one will never be able to click the "ok" button because it will never be enabled), this behaviour is quite annoying, and counter-productive, since 1) the enabling/disabling can lag the actual focus by quite a substantial amount (think in terms of slow machines or machines under memory pressure when firefox is partially swapped out (ie, all the time)).  So one can click "ok" when perhaps they shouldn't be able to because of the possible spoofing, or alternatively, one can't click OK even though the focus was brought to the dialog in question.  Furthermore, 2) in focus-folows-mouse mode, the spoofed dialog is going to partially cover the open/save dialog, such that when the user goes to move over the disabled OK button, that dialog will get the focus, and ... you'll be able to click on the OK button, thereby negating the very purpose of this spoof workaround!  Ie, the solution as per bug 260560 is completely useless in a focus follows mouse window manager.

OK, so people familar with openoffice might just be tempted to take their annoying behaviour of stealing focus all the time, but please don't do this.  Amongst many other things, it causes quite nasty feedback loops.

So, we are left with the one sane option:  We can't detect how the user's window manager behaves, and we don't know whether the user would even be fooled by the attempted spoofing, so... let's just give the user an option to disable this behaviour, please?

Reproducible: Always

Steps to Reproduce:
0. Make sure using a focus follows mouse window manager under unix.
1. click on a PDF or file that is currently set up to either download or open
2. mouse over the dialog and then mouse off.

Actual Results:  
If not operating under the latest and greatest machines, there'll be a substantial lag between the focus being given to the dialog, and the "OK" button enabled.  Try pressing the OK button before firefox has gotten around to enabling it, and nothing happens.


Expected Results:  
No matter how slow the machine is, one should always be able to press OK and it should actually so something.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Version: unspecified → 1.5.0.x Branch
Duplicate of bug: 264492
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.