1322967 - Shift+right-click triggers mousedown, mouseup, and click events

Status: REOPENED

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

Description

[Jim Black]

Attachment: rightclick.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161130233208

Steps to reproduce:

Open the attached test case.
Shift+right-click on the link.




Actual results:

The mousedown, mouseup, and click events are fired. In the attached example, the mousedown event is caught, and the link is replaced with a text node. A context menu appears, but it is the context menu for the text node, not the link. Expected entries such as "Copy Link Location" are not present.


Expected results:

The context menu for the link should appear, complete with relevant entries for the link such as "Copy Link Location". No action on the page should be triggered. Any change on the page could defeat the purpose of shift+right-click, which is to bring up the context menu for an element regardless of Javascript on the page that might disable it.

Comment 1

[Andrew Overholt [:overholt]]

Masayuki may know what's happening here.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Edge and Chrome work fine but IE doesn't.

According to the testcase <https://jsfiddle.net/d_toybox/gqppnygg/>, event target is collect even on Gecko. So, I guess that browser doesn't refer Event.target at initializing the context menu.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, however, looks like browser checks event.target of "contextmenu" event...
https://dxr.mozilla.org/mozilla-central/rev/8103c612b79c2587ea4ca1b0a9f9f82db4b185b8/browser/base/content/content.js#86

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Ben, wanna get more familiar to the events world? :)

Stone could be the mentor.

Comment 5

[Ben Tian (inactive)]

Take!

Comment 6

[Ben Tian (inactive)]

Observations:

1) On comment 0 test page, Edge, Chrome, and Firefox all pop context menu of text rather than link (no "Copy Link Location" appears). Need to check why all browsers don't behave as expected.

2) On comment 2 testcase, Edge, Chrome, and Firefox print respective logs on Win10/MacOS/Ubuntu. Firefox seems to get no 'contextmenu' event on all platforms. May need to clarify the relation with 1).

- Firefox on (Win10, MacOS, Ubuntu)
   type: mouseup, button: 2, target: body
   type: mousedown, button: 2, target: a

- Chrome on (MacOS, Ubuntu)
    type: contextmenu, button: 2, target: body
    type: mousedown, button: 2, target: a
  Chrome on Win10
    type: contextmenu, button: 2, target: body
    type: mouseup, button: 2, target: body
    type: mousedown, button: 2, target: a

- Edge on Win10
    type: contextmenu, button: 2, target: body
    type: mouseup, button: 2, target: body
    type: mousedown, button: 2, target: a

Comment 7

[Ben Tian (inactive)]

As a reference, bug 897379 comment 1 says showing default context menu for shift+right-click is intentional behavior.

"User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu."

Comment 8

[Ben Tian (inactive)]

IMO actual results in comment 0 matches HTML spec on context menu [1].

Since per comment 7 the spec doesn't specify event sequence for shift+right-click, as long as UA always shows the default context menu and doesn't fire 'contextmenu' event. Firefox behaves accordingly, regardless of whether the node is replaced or not, and meets the purpose of shift+right-click that brings up the context menu for an element regardless of "Javascript on the page that might disable it."

[1] https://html.spec.whatwg.org/multipage/forms.html#context-menus

--
Jim, what do you think?

Comment 9

[Ben Tian (inactive)]

I tend to resolve this bug as INVALID since
1) Firefox conforms HTML spec behavior (comment 8), and
2) neither Chrome nor Edge behaves as comment 0 expected results (comment 6)

Jim (and anyone else), please comment for any concern. If no I'll resolve this bug next Monday.

Comment 10

[Ben Tian (inactive)]

Resolve INVALID per comment 9. Feel free to reopen for any concern.

Comment 11

[Jim Black]

The current behavior does not meet the user need to access the context menu. This is needed in a variety of circumstances including pausing unwanted videos, removing unwanted page elements, and triggering "Inspect Element" during debugging.

Comment 12

[Jim Black]

Another example where this can come up: User wants to save an image or video on the web page. The page has disabled right click because the page author wrongly thinks this prevents people from stealing content. The user attempts to shift+right-click, but it doesn't work because the page detects it.

Or: User wants to pause an obnoxious video on the page. The page author has disabled right-click and interferes with shift+right-click because they think doing so will prevent their content from being stolen.

Or: User wants to pause an obnoxious video on the page or remove an obnoxious banner. The page author doesn't care about right clicking but has set the mousedown event to open the advertiser's web page.

Or: Page developer or user is trying to experiment with the CSS on a menu item and wants to bring up "Inspect Element". Firing mousedown on the menu item triggers the associated action and removes the menu entirely.

Comment 13

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)