Closed Bug 1677334 Opened 4 years ago Closed 3 years ago

Control-click on a link with a scripted click handler shows the context menu, but also is interpreted as a normal click

Categories

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

Unspecified
macOS
defect

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- fixed

People

(Reporter: jesup, Assigned: edgar)

References

(Regression)

Details

(Keywords: regression)

Attachments

(4 files, 1 obsolete file)

This is tested on Nightly with fission on on a Mac, btw.

If I control-click a newtab (pocket) story, it navigates the page to the article while also opening the context menu. I also see this if I control-click an pocket article suggested at the end of a pocket article ("More stories from Pocket"). It does not happen on normal pages.

My guess is it's something specific to Pocket, and not a browser bug per se.

Note: right-click (two-finger click on a mac laptop) doesn't have this problem

Flags: needinfo?(gsuntop)

I've seen this with links in Slack (in Firefox), so I don't know if it's specific to the new tab page.

Simple test case:

<!DOCTYPE html>
<script>window.onload = function() {
  document.getElementById("a").onclick = function(e) {
    window.open("https://rfc-editor.org/")
  }
}</script> 
<a id="a" href="https://developer.mozilla.org/">Link</a>

Clicking normally opens a new tab and navigates the page. Two-finger clicking opens the context menu. Control-clicking displays the context menu and opens a new tab, but doesn't navigate (as if e.preventDefault() had been called).

Also, this doesn't seem to happen in Developer Edition, so MozRegression should work here.

I'm not sure what component this belongs in, but I'm going to assume it's not the new tab page.

Component: New Tab Page → Untriaged
Summary: Control-click on an about:newtab story shows the context menu, but also is interpreted as a normal click → Control-click on a link with a scripted click handler shows the context menu, but also is interpreted as a normal click
Attached file jld.html

I tried using mozregression, but the bug reproduced on older Nightlies (and not more recent non-Nightly builds). In discussion in #dom:mozilla.org on Matrix, Gijs found the pref that controls this behavior: dom.event.treat_ctrl_click_as_right_click.disabled.

I've confirmed by testing the Nightly builds before and after bug 1615732 landed that that is the regression point.

Regressed by: 1615732
Has Regression Range: --- → yes

Note that this doesn't repro in Release 82 or 83. This was probably regressed by bug 1615732; this is a Mac bug (ctrl-click works differently on Windows and Linux)

You can also see this in the demo for auxclick: https://developer.mozilla.org/en-US/docs/Web/API/Element/auxclick_event -- on release, control-click is an auxclick; on nightly it's a click

OS: Unspecified → macOS

Hi Randell Jesup!
Could you please add some screen recordings with the problem? Also, add more steps and expected results might help us to reproduce it.
I used the file attached ( jld.html ) on latest Nightly version 85.0a1 (2020-11-18) on macOS 10.14 with Fission checked and after doing cmd-click on the "link" 2 tabs were opened, one with https://www.rfc-editor.org/ and the other with https://developer.mozilla.org/en-US/. Is this the expected behavior? Thanks!

Flags: needinfo?(rjesup)

I will set a component to have a starting point for this. If this is not the right component please feel free to route this ticket to the corresponding team, thanks!

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core

Step to reproduce: Control-click the link (not command)

Expected: Context menu appears; no tabs are opened, and there are no other side effects

Actual: Context menu appears and one tab is opened (to rfc-editor.org)

Flags: needinfo?(gsuntop)

Edgar, is it intentional that we run onclick for ctrl+click, if dom.event.treat_ctrl_click_as_right_click.disabled is true?

Flags: needinfo?(echen)

Hmm, last time I test, Chrome doesn't trigger click event, but Safari does.
But I test again now, neither Chrome nor Safari triggers a click event for ctrl+click.
Maybe Safari changed the behavior? Anyway, I think we should not trigger click event for ctrl+click to align with others.

Assignee: nobody → echen
Flags: needinfo?(rjesup)
Flags: needinfo?(echen)
Severity: -- → S3
Priority: -- → P2

Chrome and Safari doesn't genereate click event when contorl key is pressed, either.

Those check was add in bug 1615732, now we align with other browser to not
send click event for Control + left-mouse-button, so we don't need these checks
anymore.

Depends on D109903

Attachment #9211791 - Attachment description: WIP: Bug 1677334 - Part 1: Don't generate click event if control key is pressed on Mac; → Bug 1677334 - Part 1: Don't generate click event for mouse-left-down with ctrl key is pressed on Mac; r=masayuki

Now we won't dispatch click event at all when ctrl key is pressed on Mac, so we
don't need those Mac-specific checks.

This patch reverts part of https://hg.mozilla.org/mozilla-central/rev/d8726d18021e
and revise the tests accordingly.

Now we won't dispatch click event at all when ctrl key is pressed on Mac, so we
don't need those Mac-specific checks.

This patch reverts part of https://hg.mozilla.org/mozilla-central/rev/69785d2dfbf2
and revise the tests accordingly.

Depends on D110608

Attachment #9211850 - Attachment is obsolete: true
Pushed by echen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b99a345ba71b
Part 1: Don't generate click event for mouse-left-down with ctrl key is pressed on Mac; r=masayuki
https://hg.mozilla.org/integration/autoland/rev/74f97ab4c1d3
Part 2: Remove Mac-specific check for click event on xul frame; r=NeilDeakin
https://hg.mozilla.org/integration/autoland/rev/0f285de21746
Part 3: Remove Mac-specific check for click event; r=Gijs
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: