102956 - download progress dialog: using spacebar to activate Close button results in dataloss

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[sairuh (rarely reading bugmail)]

ran into this while testing bug 79862. basically, if use the spacebar to
activate the Close button in the download progress dialog --instead of a
mouseclick-- the file i tried to download is not saved at all.

pls do reassign as needed!

found using 2001.10.03.09-trunk *and* 2001.10.02.05-branch commercial bits on
winNT. this is *not* a problem [so far] on linux or mac os 10.0.4 [trunk or branch].

recipe:

0. make sure you have your settings such that the helper app dialog appears for
this test ;), and that the download progress dialog will persist.1. go to
http://mozilla.org and scroll down to the "nightly builds" section.
2. click on any of the download links, eg, the one for "mac os x".
3. when the helper app dialog appears, make sure "save this file to disk" is
selected.
4. choose a destination folder, then click OK.
5. the download progress dialog appears...wait for the download to complete,
when the "cancel" button turns into "close".
6. using the tab key [for non-win32 systems i had to click first to gain initial
focus, see bug 79862], navigate to the "close" button so that it displays the
focus ring.
7. hit the spacebar to activate "close".

results: the "close" button depresses and the download progress dialog is
dismissed. however, check the destination folder: no file has been saved!

in fact, before step (7), i even checked the destination folder, and the file
*was* there. somehow using the spacebar for "close" acts as if it's a "cancel"
--which is rather odd...

side note: if i click "close" with the mouse, this is not a problem.

Comment 1

[sairuh (rarely reading bugmail)]

tentatively nominating for the branch...even though there is a non-keyboard
workaround. thoughts?

would be good to fix in the trunk, though.

anyone else see this?

Comment 2

[Jaime Rodriguez, Jr.]

Pchen - This looks interesting ... What are your thoughts? Is this worthy of a 
nsbranch+

Comment 3

[Aaron Leventhal]

Is this bug 103088?

Comment 4

[scalkins]

I see this on Win2k also.(win32 2001-10-03-05Brnch)
This would be particularly bad for users on dialup who've waited a long time for
large downloads.

Comment 5

[sairuh (rarely reading bugmail)]

*** Bug 103088 has been marked as a duplicate of this bug. ***

Comment 6

[timeless]

like staroffice6? yep mozilla ate it for me.

Comment 7

[Jaime Rodriguez, Jr.]

what are the chances this is gonna make 094.

Comment 8

[Aaron Leventhal]

-> Bill Law, who is already working on this

Comment 9

[Bill Law]

I think the problem is that we change the onclick handler for the button when it
changes to "Close" but the onclick handler isn't invoked when you press the
spacebar, unfortunately.  I'll have to figure out how to do this properly.

BTW, the fix went in for bugs 67803, et al and it doesn't fix this (actually,
probably makes it a bit worse).  That was on the trunk, though.

I can have a fix tomorrow.  Please mark as nsbranch+ if it needs fixing on the
branch.

Comment 10

[Blake Ross]

I may not understand the issue entirely, but all buttons should be using
oncommand, not onclick, as that triggers in the normal OS manner (in this case
spacebar) as well as on click.

Comment 11

[Jaime Rodriguez, Jr.]

Is this a regression? Did this exist in Netscape 6.1?

Comment 12

[Bill Law]

Blake: You understand; the problem is that mscott wired up Close to use onclick.
 That's the problem.

Jaime: This seems to be broken the same way in NS6.1.

Comment 13

[Jaime Rodriguez, Jr.]

Thanks for the update ... Much appreciated.

Comment 14

[Peter Trudelle]

Marking nsbranch+, assuming the fix is as simple and safe as it sounds.  If not,
we can live with this a while longer. 

Comment 15

[Bill Law]

Attachment: Simple patch; leaves button the same but blocks cancel going to exthandler if download has completed

Comment 16

[Paul Chen]

Comment on attachment 53300 [details] [diff] [review]
Simple patch; leaves button the same but blocks cancel going to exthandler if download has completed

r=pchen

Comment 17

[David Hyatt]

sr=hyatt

Comment 18

[Jaime Rodriguez, Jr.]

Sorry, its too late to take this one = PDT-. Let's get it inthe trunk for the
next release.

Comment 19

[Bill Law]

fixed (on trunk only)

Comment 20

[sairuh (rarely reading bugmail)]

excellent! vrfy fixed using 2001.10.18.06-trunk comm bits on winNT.