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)
Tracking
()
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.
Reporter | ||
Comment 1•4 years ago
|
||
Note: right-click (two-finger click on a mac laptop) doesn't have this problem
Updated•4 years ago
|
Comment 2•4 years ago
|
||
I've seen this with links in Slack (in Firefox), so I don't know if it's specific to the new tab page.
Comment 3•4 years ago
|
||
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.
Reporter | ||
Comment 4•4 years ago
|
||
Comment 5•4 years ago
|
||
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.
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
|
||
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
Updated•4 years ago
|
Comment 7•4 years ago
|
||
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!
Comment 8•4 years ago
|
||
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!
Comment 9•4 years ago
|
||
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
)
Updated•4 years ago
|
Comment 10•3 years ago
|
||
Edgar, is it intentional that we run onclick for ctrl+click, if dom.event.treat_ctrl_click_as_right_click.disabled
is true?
Assignee | ||
Comment 11•3 years ago
•
|
||
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 | ||
Updated•3 years ago
|
Assignee | ||
Comment 12•3 years ago
|
||
Assignee | ||
Comment 13•3 years ago
|
||
Chrome and Safari doesn't genereate click event when contorl key is pressed, either.
Assignee | ||
Comment 14•3 years ago
|
||
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
Assignee | ||
Comment 15•3 years ago
|
||
Assignee | ||
Comment 16•3 years ago
•
|
||
Assignee | ||
Comment 17•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 18•3 years ago
|
||
Assignee | ||
Comment 19•3 years ago
|
||
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.
Assignee | ||
Comment 20•3 years ago
|
||
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
Updated•3 years ago
|
Comment 21•3 years ago
|
||
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
Comment 22•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b99a345ba71b
https://hg.mozilla.org/mozilla-central/rev/74f97ab4c1d3
https://hg.mozilla.org/mozilla-central/rev/0f285de21746
Updated•3 years ago
|
Description
•