405886 - Remove the "Open File" button at the right of every download row

Status: VERIFIED FIXED

(Toolkit :: Downloads API, enhancement, P1)

Description

[Madhava Enros [:madhava]]

[actually nominating for wanted]

As shown in this mockup (attached to bug 397655) :
https://bugzilla.mozilla.org/attachment.cgi?id=288692

Given that a user can open a downloaded file in the DM by double-clicking on the row, and, failing that by right-clicking on the row and selecting "Open," the value of having a button here is outweighed by the simplicity we can achieve by removing it.

Comment 1

[Shawn Wilsher :sdwilsh]

I must have missed that in the mockup.  I don't think most users are aware that you can open a download by double clicking on it (I know I never did until I saw the code for it).  Are we sure this is a good idea?

Comment 2

[aja+bugzilla]

FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility point of view.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Oh, nice hint. I'm using Firefox since ages and haven't recognized that. I have to agree that this isn't a good idea to remove this small icon even it's not accessible by keyboard.

Comment 4

[aja+bugzilla]

(In reply to comment #2)
> FWIW, seems to me to be bad from a keyboard/non-pointing device/accessibility
> point of view.
> 
Partial retraction, if the same info's available in context menu:
Context menu can be accessed via Shift-F10 (or via Menu key on 104-key keyboards).
Discoverability may remain an issue.
 

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

While I understand the worry that removing the button might make it less obvious, people are pretty used to double-click = open interactions and I think it will become pretty natural when the button is removed. We could add a tooltip saying "Double click to launch..." if people really think it'll be totally undiscoverable.

Right now people are seeking to a very small target to launch things, and by removing that target, perhaps counter-intuitively, we believe it will be easier for them to try the ol' double click.

Comment 6

[Shawn Wilsher :sdwilsh]

The other issue is how accessible is this solution?  I'm betting it's not...

Comment 7

[Ed Lee :Mardak]

Perhaps we should let the user hit enter to trigger the double clicking action.

Comment 8

[Ed Lee :Mardak]

Attachment: screenshot of v1

Killed the open button. Includes the other patches for removing info and adding time.

Comment 9

[Ed Lee :Mardak]

Attachment: v1

Remove UI element and styling. Functionality stays around.

Comment 10

[Ed Lee :Mardak]

For my own sanity.. .hg/patches Ed$ hg qapp | awk '{ print "head -1", $1}' | sh

Bug 392097 - only showing 7 days of download history, until I search, then I see more items
Bug 405884 - List date/time of download for each download shown
Bug 406230 - Vertically align download icons in the center
Bug 394516 - Figure out a remaining-time rounding scheme for minutes -> hours/days
Bug 406857 - Don't clear referrer when restarting downloads
Bug 405893 - Search should match TLDs as well as download file names
Bug 405888 - Remove the "Information" button at the right of every download row
Bug 405886 - Remove the "Open File" button at the right of every download row

Comment 11

[Mike Connor [:mconnor]]

should probably support whatever the OS filepicker shortcut is to open a file in a file manager window (i.e. Cmd+O on Mac in Finder)

Comment 12

[Shawn Wilsher :sdwilsh]

I still want to hear from someone who specializes in a11y on this...

Not sure who to cc offhand.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #12)
> I still want to hear from someone who specializes in a11y on this...
> 
> Not sure who to cc offhand.

I think that Aaron or Marco could help.

Comment 14

[Aaron Leventhal]

It's probably okay if pressing Enter opens the file. Marco, what do you think?

I hope this means that the one remaining button on there can use the extra space and become easier to see.

Comment 15

[Ed Lee :Mardak]

Aaron: There's actually no buttons in the common case (a completed download). See attachment 291680 [details] for an example. There'll be a retry button for canceled/failed downloads though.

Comment 16

[Aaron Leventhal]

I think users will figure it out, because on the desktop you open a file with Enter or double click.

Edward, will you put Enter in as a way to open the file?

Do some of the features require use of the context menu? If so then please consider this: if some features are only available in the context menu, you should test to see if you can get a context menu with the keyboard on a Mac. Now that Mac is gaining popularity we probably shouldn't ignore keyboard-only users on it. However I don't know what the status is of our support for a context menu key on Mac. I think we used to support Control+space but no longer do.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #16)
> Now that Mac is gaining popularity we probably shouldn't ignore keyboard-only
> users on it. However I don't know what the status is of our support for a
> context menu key on Mac. I think we used to support Control+space but no longer
> do.

Correct. I already stated this in bug 357540. Currently there is no way to access any of the features from a keyboard only device. Each function of the download manager (there are several other bugs around) is accessed via the context menu. Aaron, shall I file a new bug for general accessibility on Mac?

Comment 18

[Aaron Leventhal]

> Aaron, shall I file a new bug for general accessibility on Mac?
Shouldn't bug 357540 cover it? It makes no sense to me that it was minused.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #18)
> > Aaron, shall I file a new bug for general accessibility on Mac?
> Shouldn't bug 357540 cover it? It makes no sense to me that it was minused.

Sure. But I was a bit unclear, sorry. I meant a general bug for missing access to features of the new download manager. But if we get back the shortcut it will be automatically fixed. So just forget that part of my last comment.

Comment 20

[Shawn Wilsher :sdwilsh]

Comment on attachment 291542 [details] [diff] [review]
v1

Update gnomestripe (you seem to forget this :p)

Make sure that enter works per Aaron's comments (I think it does).

r=sdwilsh with comments fixed.

Comment 21

[Ed Lee :Mardak]

(In reply to comment #20)
> Make sure that enter works per Aaron's comments (I think it does).
Seems like no.. bug 408350.

Technically we could land this before bug 408350 is fixed, but there would be a short period of time where the user would have to double click to open the download.

But I suppose technically, being in the context menu without a keyboard shortcut isn't much better either...

Should this wait for bug 408350?

Comment 22

[Aaron Leventhal]

Please wait for that one, we're dogfooding daily builds. Many users that are dog fooding do not use a mouse and are using Firefox 3 daily builds exclusively.

Comment 23

[Reed Loden [:reed]]

Uh, neither enter nor double-click works for me. I see adding enter as an opening function is bug 408350, but what about double-click? It definitely doesn't open the download for me. Until both of those are fixed, please leave the button.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007121504 Minefield/3.0b3pre ID:2007121504

Comment 24

[Reed Loden [:reed]]

(In reply to comment #23)
> Uh, neither enter nor double-click works for me. I see adding enter as an
> opening function is bug 408350, but what about double-click? It definitely
> doesn't open the download for me. Until both of those are fixed, please leave
> the button.

Ok, it seems that everything that doesn't exist anymore (as in, in my /tmp folder) fails silently when open is attempted. For the one thing in my download history (at least for the last 7 days) that existed, it didn't open anything, as it was a binary. I downloaded an html file to a location besides /tmp, and it seems to work, though it does not give the same "open" indication that clicking the open button does, which can leave you wondering if something is really open or not. Needs to be some better indication that a file doesn't exist when open is attempted.

Comment 25

[Ed Lee :Mardak]

Checking in toolkit/mozapps/downloads/content/download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.48; previous revision: 1.47
done
Checking in toolkit/themes/gnomestripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.4; previous revision: 1.3
done
Checking in toolkit/themes/pinstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.22; previous revision: 1.21
done
Checking in toolkit/themes/winstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/winstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.26; previous revision: 1.25
done

Comment 26

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2007121802
Minefield/3.0b3pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre)
Gecko/2007121801 Minefield/3.0b3pre

and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2007121802
Minefield/3.0b3pre

Comment 27

[Stephen Donner [:stephend] Not actively reading bugmail]

Smitten from https://litmus.mozilla.org/show_test.cgi?id=3976

in-litmus+