Open
Bug 1322967
Opened 8 years ago
Updated 2 years ago
Shift+right-click triggers mousedown, mouseup, and click events
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Tracking
()
REOPENED
People
(Reporter: tramspap, Unassigned, Mentored)
References
()
Details
(Keywords: parity-chrome, parity-edge)
Attachments
(1 file)
358 bytes,
text/html
|
Details |
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 2•8 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(masayuki)
Whiteboard: [parity-Edge][parity-Chrome]
Comment 3•8 years ago
|
||
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
Updated•8 years ago
|
Priority: -- → P2
Comment 4•8 years ago
|
||
Hi Ben, wanna get more familiar to the events world? :) Stone could be the mentor.
Mentor: sshih
Flags: needinfo?(btian)
Comment 6•8 years ago
|
||
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•8 years ago
|
||
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."
See Also: → 897379
Comment 8•8 years ago
|
||
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?
Flags: needinfo?(tramspap)
Comment 9•8 years ago
|
||
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•8 years ago
|
||
Resolve INVALID per comment 9. Feel free to reopen for any concern.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Updated•7 years ago
|
Flags: needinfo?(tramspap)
Reporter | ||
Comment 11•7 years ago
|
||
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.
Reporter | ||
Comment 12•7 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Updated•7 years ago
|
Assignee: ben.tian → nobody
![]() |
||
Comment 13•6 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome,
parity-edge
Whiteboard: [parity-Edge][parity-Chrome]
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•