260323 - Right-click on Open, Remove, or Cancel in the download manager executes the command

Status: VERIFIED INVALID

(Toolkit :: Downloads API, defect)

Description

[Craig Cockburn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

After downloading, right click the "open" link in download manager to select
"open in containing folder". However, the file opens rather than showing the
folder. I am noting this as a security problem because rather than viewing the
file location in explorer, the file executes and could contain malicious
material. I noticed this problem when downloading a file with two dots in the
filename and received a warning (from meda player) about the filetype and I
wanted to view the file location details via the open link to see what the
problem was.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Ali Ebrahim]

WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

Can you give me the URL of a file where this happened, and also the full path
where you downloaded it to?

Also, if possible, please unmark this as a security sensitive bug. It's not.

Comment 2

[Craig Cockburn]

This happens on every download, irrespective of file type or download location.
You have to right click on the "open" link to replicate. Right clicking
elsewhere in the item area works fine.

Comment 3

[Daniel Veditz [:dveditz]]

Confirming, the "Open" and "Remove" links do not distinguish between right and
left clicks. Other parts of the browser make this distinction, and some features
are available only if you right click on a link itself (open link in new
window/tab, whichever isn't your default meta action;  copy or save link, etc.). 

We've trained people to expect this, and if users somehow got wind of the "open
folder" feature they are far more likely to try right-clicking on the link
itself than to think of trying random spots in the item area.

"unsafe" types still get the usual warning dialog, same as a regular click. I
agree this is not a security hole (an attacker couldn't mount an attack assuming
users would click for an obscure feature in the wrong spot) but it's still
potentially dangerous behavior if you assume that some part of the time people
are using the open-in-folder feature to check suspicious downloads.

Comment 4

[Nitin (vfwlkr)]

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

Comment 5

[Nitin (vfwlkr)]

Adjusting summary based on comment 3 and bug 261127

Comment 6

[Chris Moore]

Attachment: before right-clicking

about to right-click on 'open'

Comment 7

[Chris Moore]

Attachment: after right-clicking on 'open'

after right clicking - Word has opened and a context menu has appeared

Comment 8

[Chris Moore]

Attachment: just the 'Word' window

If I use 'alt prt sc' to snap just the Word window, the context menu appears in
the snapshot.  Note that even if the context menu was overlapping the edge of
the Word window in reality, it appears entirely inside the Word window in the
snapshot.

Comment 9

[Logan Ingalls]

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

Comment 10

[Logan Ingalls]

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

Comment 11

[Logan Ingalls]

Adding "Cancel" to the list of links.  Also, this depends on bug 260879.

Comment 12

[Jean-Marc Desperrier]

A new user of the 1.5 release just signaled this to me, and it definitively makes it look unpolished :-(

Right now, right click on the 'open'/'cancel' pseudo-link in the download manager both does the left click action and opens the contextual menu.

I don't want bug 260879 to act as a straw man here.
In the future, we might want button instead of links, but 1.5 needs an update where the behavior is corrected. IMHO it won't be long before this gets in the top of the duplicate list.

Comment 13

[Peter Weilbacher]

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

Comment 14

[Nickolay_Ponomarev]

This is a general problem with the <label class="text-link" onclick="..."/> pattern, and it affects at least the Get Extensions link in the addons window too.

We could add the button check to each of the handlers or use a different event to indicate that user followed a link ('command'?) The latter appeals more to me.

Comment 15

[Shawn Wilsher :sdwilsh]

The links are no longer used and have been replaced with buttons, solving this problem.  This bug is no longer valid.

Comment 16

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

Verified