download manager dbl-click offers the same action as the "open" link




15 years ago
11 years ago


(Reporter:, Assigned: bugs)


Bug Flags:
blocking-aviary1.0PR -
blocking-aviary1.0 -
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040716 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040716 Firefox/0.9.1+

when you have a finished item in the download manager, you have three
easy-to-access "functions".
 a) the "Open" link function;
 b) the "Remove" link function;
 c) the dbl-click function;

why would you want to have 2 of those 3 easy-to-access method to do the same
thing ... if I dbl-click, I will open/execute the file; if I click on the "open"
link, I will get the same result.

Solution: the download manager dbl-click behaviour should be changed to "show
containing folder" or change the "open" link to a "show" link (like it was in
the first versions of this download manager if I remember well).

I would change the dbl-click behaviour because it's easier to dbl-click by
accident on an item rather than going with your mouse on a smaller area and then
click. Safer to make the double click to show the file in its folder.

Reproducible: Always
Steps to Reproduce:

Comment 1

15 years ago
quick reminder on this. it should be done before 1.0 final so the product looks
a little bit more professional and pleases more users

Comment 2

15 years ago
okey only two lines to change in download.xml

old code to replace from download.xml
#342 <xul:label value="&;" class="link" 
#343  onclick="this.parentNode.parentNode.parentNode.fireEvent('open');"/>

new code to put in download.xml
#342 <xul:label value="&cmd.openWith.label;" class="link" 
#343  onclick="this.parentNode.parentNode.parentNode.fireEvent('openWith');"/>

I guess it's a question of 3 sec now to change the code in branch&trunk, so
please do it (and it will be consistent with your help system which shows a
screenshot of the download manager with the 'Show' link)

Comment 3

15 years ago
okey seems like I mixed some stuff ...

in this file
mozilla/ toolkit/ locales/ en-US/ chrome/ mozapps/ downloads/ downloads.dtd

you need to add this line:
<!ENTITY cmd.showshort.label "Show">

and then in this file
mozilla/ toolkit/ mozapps/ downloads/ content/ download.xml

you need to replace the lines 342 and 343 with this:
#342 <xul:label value="&cmd.showshort.label;" class="link"
#343  onclick="this.parentNode.parentNode.parentNode.fireEvent('show');"/>

sorry I don't have a proper cvs access, I'm just downloading nighties from
internet cafees while being in vacation


15 years ago
Flags: blocking-aviary1.0PR?


15 years ago
Flags: blocking-aviary1.0?
I'd wait until bug 240696 is in before making a patch. Might be a dupe, can't
find one right now. 

If I understand clearly, you want to change the default doubleclick action from
"Open File" to "Show Folder"?

Comment 5

15 years ago
yep ... for two reasons

 a) we already have a "open" hyperlink easy to access
 b) dbl-click could make users run something accidently

Comment 6

15 years ago
It's a valid bug, but this shouldn't be nominated as a blocker.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Unless you're now a driver, please do not touch the blocking flags, other than
to request a blocker (?).

See .


14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0-


14 years ago
Ever confirmed: true

Comment 8

14 years ago
I will try to make a patch in the coming days.

IMO the best solution would have been to make dbl-click open the container
folder but unfortunately firefox 1.0 was shipped with this "interface bug" and
people are now maybe too used to dbl-click for execution so it would be more
polite to change the "Open" hyperlink to something like "Open Containing Folder"... 
Flags: blocking-aviary1.1?


14 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 9

14 years ago
Created attachment 180666 [details] [diff] [review]
replace the 'open' hyperlink to 'show'

Et voila.

This patch adds a new item to translate, found in the 
/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.dtd file.


14 years ago
Attachment #180666 - Flags: review?(mconnor)
Comment on attachment 180666 [details] [diff] [review]
replace the 'open' hyperlink to 'show'

Show isn't specific, and could easily be misconstrued to mean "Show File"

I'm not sold on the value here.  Open exists for user-discoverability reasons,
and because double-clicking is something all users can do (Apple's HIG makes
this point strongly).  Requiring double-click or right-click to open isn't a
good idea for speed of navigation.

As a note, in the default download-everything-to-one-place setup, this is
redundant too, since there's a button at the bottom of the manager.

For a user incapable of double-clicking (tremors, etc), this is a usability
regression, plain and simple.
Attachment #180666 - Flags: review?(mconnor) → review-
Redundancy isn't obvious, its not like redundant menuitems that have the same
function.  Sometimes duplication/overlap is necessary.
Last Resolved: 14 years ago
Resolution: --- → WONTFIX

Comment 12

14 years ago
In fact the 'Show' item was really showing the file within its directory.

Would change the dbl-click behaviour be satisfactory?

"As a note, in the default download-everything-to-one-place setup, this is
redundant too, since there's a button at the bottom of the manager."

Wrong, the button at the bottom of the page opens the folder, while the 'Show'
link opens the folder AND select the file (can be useful if you have +/- 100
files in a folder)

I understand your point but I still think offering a quicker access to a nice
function like this one would improve the download manager experience. I initialy
changed the dbl-click behaviour and then thought maybe everybody used the
dbl-click to open the file and would be a smoother transition if we changed the
hyperlink but your right on all ppl not being able to make a dbl-click.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.