I think that we should need to fix this bug until ship to release new DL manager. Old toolkit DL manager need double-clicking to open a downloaded files. So this difference will user confusing. And Its confusing will be security risk. I set up the malefic attacking scenario: 1. A attacking site make a file having malware is downloaded. This process is not needed by user. 2. User will think that "What is this downloaded file?", he may click it with single clicking. Thus its malware will be opened. 3. As the result, malefic attacking will success... So this is a potential security risk. Firefox user recognize that it need to open with double-clicking. But the current behavior breaks this recognition. Therefore this is a *potential*, but we cannot overlook it. This is so bad because the double-clicking behavior of toolkit DL manager is common behavior in users.

Comment on attachment 675870 [details] [diff] [review] proposed patch there is no other panel or popup widget in our code using double click as far as I know so this would be special, maybe even confusing to the user. So this should be avaluated by UX in the first place. I'm not sure about the security issue, what I can tell is that commonly the OS has already some sort of protection against downloaded executables, but for example Safari (that has a similar panel) does indeed force double click to open, and this could have been taken into account in that choice.

likely if we go for double click we need to remove the hover selection and go back to a classical click-to-select

(In reply to Marco Bonardo [:mak] from comment #2) > there is no other panel or popup widget in our code using double click as > far as I know so this would be special, maybe even confusing to the user. > So this should be avaluated by UX in the first place. > I'm not sure about the security issue, what I can tell is that commonly the > OS has already some sort of protection against downloaded executables, but > for example Safari (that has a similar panel) does indeed force double click > to open, and this could have been taken into account in that choice. I see. This may confuse to user about the behavior of panel/popup. However, totally, I think that the current "single-click" behavior which is different from toolkit DL manager will confuse much than it. (And though the current behavior has a non-petty & potential security issue. Because downloading files is a one of the exception of browser sandbox.) (In reply to Marco Bonardo [:mak] from comment #3) > likely if we go for double click we need to remove the hover selection and > go back to a classical click-to-select Umm...... I can't answer at this time. Let me think about it.

The panel already got a security review (https://wiki.mozilla.org/Security/Reviews/Firefox10/PanelDownload) but looks like this issue has not been reported in the notes, so either was not considered an issue, or not evaluated. We'd really like security team feedback on this.

Comment on attachment 675870 [details] [diff] [review] proposed patch Daniel, sorry if I nag you, could you please point us to someone in the security team to evaluate this?

Click or double-click are about the same from a security standpoint: if the file is bad either way the user is intending to open it and they're in trouble. Single-click things are easier to "click-jack", but the solution to that is to keep the panel floating over the page content so it can't be obscured and close the panel if some other window is brought to the front. Whether you single or double click is a UX decision. Whichever least surprises the user is best, and that depends on how the rest of the UI and platform works.

Comment on attachment 675870 [details] [diff] [review] proposed patch Thank you Daniel. So doesn't look like we consider this security sensitive, what's left is the UX decision on the kind of interaction we want here. Thus I leave this open for feedback from UX team, if single-click ends up being the wanted interaction this will just be wontfixed.

Single-click is the desired interaction.

God forbid it follows native platform conventions 'ey.

(In reply to Stephen Horlander from comment #9) > Single-click is the desired interaction. Stephen, would you tell me about the reason? DL panel's single-click is different behavior from toolkit DL manager which is used by all user in now. I seem this behavior difference may make user some confuses. How do you think about it? please tell me more description...

(In reply to Tetsuharu OHZEKI [:saneyuki_s] from comment #11) > (In reply to Stephen Horlander from comment #9) > > Single-click is the desired interaction. > > Stephen, would you tell me about the reason? > DL panel's single-click is different behavior from toolkit DL manager which > is used by all user in now. I seem this behavior difference may make user > some confuses. How do you think about it? please tell me more description... The key difference is that the new panel is a download launcher and not a download manager. Double-click as a secondary action to open files/items is a direct result of single-click acting on the primary action of selection. If we allowed selecting items in the download panel then we would need double-click as a secondary action for opening.

(In reply to Stephen Horlander from comment #12) > The key difference is that the new panel is a download launcher and not a > download manager. > > Double-click as a secondary action to open files/items is a direct result of > single-click acting on the primary action of selection. > > If we allowed selecting items in the download panel then we would need > double-click as a secondary action for opening. Thank you. As a download launcher, single-click behavior naturally. I agree. Below is my subjective thought: Major desktop file managers (Windows Explorer, OSX Finder, GNOME Nautilus) use double-click as a action to open/execute local files in default preference. I think that the behavior of opening a file should be follow the default preference of file manager as possible. Because it's may cause a user stress if file is opened in big applications & the launched application needs a large hardware resource. The behavior of toolkit manager may be considered about it. If we should change DL panel behavior, I would like to make a patch.

Thanks everyone for staying constructive in the discussion, appreciate that.

(In reply to Marco Bonardo [:mak] from comment #14) > Thanks everyone for staying constructive in the discussion, appreciate that. Thank you for being mentor, Marco.

There's a legitimate security concern here (and with other doorhangers), but I agree that a double-cick is not the right solution. The basic scenario comes from it being possible to trick a user to click a certain point in the future (play my twitchy punch-the-monkey game! click click click click...). So it's plausible to get a user to click an item or button in chrome UI that extends over the content area. I don't think this is hugely likely to be an attack vector for the download panel, because we only show the panel contents the first time it's used. [Right?] So once a user has downloaded anything, the panel won't be shown unless the users explicitly opens it (which isn't directly trickable). I'd suggest that we instead look for ways to make these tricks harder, while not punishing normal usage. As an off-the-cuff example: we could suppress 1-click-to-launch if the pointer was already over the panel when it opened. Or add a small delay so your brain has a chance to notice a panel opened before your finger reflexively clicks.

(In reply to Justin Dolske [:Dolske] from comment #16) > I don't think this is hugely likely to be an attack vector for the download > panel, because we only show the panel contents the first time it's used. > [Right?] Right. > I'd suggest that we instead look for ways to make these tricks harder, while > not punishing normal usage. As an off-the-cuff example: we could suppress > 1-click-to-launch if the pointer was already over the panel when it opened. > Or add a small delay so your brain has a chance to notice a panel opened > before your finger reflexively clicks. This still assumes the page can open the panel for the user, that is untrue, the only way to open the panel is clicking the button in the toolbar.

(In reply to Marco Bonardo [:mak] from comment #17) > This still assumes the page can open the panel for the user, that is untrue, > the only way to open the panel is clicking the button in the toolbar. Yep, I was (unclearly) talking about the problem in abstract (with an eye towards a general solution other doorhangers, since it's come up before).