This is bug 245737 but for the download window which seems to completely ignore this setting. See URL for people complaining about the delay, then noting that setting the delay to 0 does nothing. From kb.mozillazine.org: security. dialog_enable_delay Integer Amount of time in milliseconds to disable buttons on security-sensitive dialog boxes. Default value is 2000. Thus, it seems that, like with bug 245737, this got missed on the transition from seamonkey to aviary.

For reference: this was introduced in bug 260560. The problem here is that the timeout is only 250 ms while security.dialog_enable_delay defaults to 2000 ms. I guess this means that we should use the lower of the two values (security.dialog_enable_delay or 250). Alex: Would that be acceptable?

Why do we have two different amounts of time for the security fix (250 and 2000)? In general the shortest delay that also enables us to protect users from being tricked into clicking the button is preferable.

Because installing an extension is always risky, while opening a file with a default handler chosen by Firefox is only risky if (1) Firefox is mistaken about what kinds of files are 'executable' or (2) your media player's MP3 decoder has a memory safety bug. Not sure it's right to have two different delays, but I think that was the rationale at the time.

>while opening a file with a >default handler chosen by Firefox is only risky if (1) Firefox is mistaken >about what kinds of files are 'executable' or (2) your media player's MP3 >decoder has a memory safety bug. Having no delay for files that we do not believe to be dangerous (as opposed to a shorter delay) seems to make sense, right?

Hard to say. Is your MP3 player app as up to date as your web browser?

Just because we think some application/file-type is safe now doesn't mean it won't be safe in the future :(

>Just because we think some application/file-type is safe now doesn't mean it >won't be safe in the future :( I think it's important to consider that there is a real and significant cost to making 260 million people wait 2500 milliseconds even once (20.5 human years). So we should only pull out a delay if we are absolutely totally sure there is a real threat.

Please don't use "260 million users" arguments to advance your pet bugs, especially when there's controversy beyond "but it would be hard to implement!". There's real and significant cost to putting 260 million users at a small amount of risk of having their computers get very owned, too. It's hard to compare those costs. You might also be interested in bug 363142, "Replace delay in security dialogs with something else". Maybe we can come up with something that's so safe and fast that we don't need to argue over whether the file-opening dialog needs it.

I was half joking, and I don't think this really counts as one of my pet bugs (I keep a special list of those), but obviously what we need to do is figure out a novel way that both keeps users safe and doesn't randomly murder the occasional aggregated 20 year old. I'll follow up in bug 363142.

(In reply to comment #8) > Maybe we can come up with something that's so safe and > fast that we don't need to argue over whether the file-opening dialog needs it. Steal apple's "slide to unlock" with a "Slide to confirm". A person couldn't arbitrarily click "ok", but they can swoop the slider quickly.

sorry, in addition to patent issues, sliding is trivially gameable and the reason we have timers in the first place is because jesse showed dialogs were gameable.

This is more of security issue than a polish issue

Sorry to drag up the dreges, but the button is greyed out, even when using "save to disk". If you assume that the save routine itself is not buggy, then I see no problem with disabling the grey-out unless open with is selected.