In https://bugzilla.mozilla.org/show_bug.cgi?id=1421323 we changed
the actions API to synthesise a contextmenu event on macOS and
Linux, but not Windows. I asked as part of the review whether this
applied to Linux, which was confirmed.

But https://github.com/mozilla/geckodriver/issues/1492 and various
comments on the aforementioned bug disagree. The conclusion I draw
from the user feedback is that we should not be firing the contextmenu
event on Linux, but instead have the same behaviour as on Windows,
which is to open a new tab.

Hi Andreas, I'm one of the people who gave feedback on the original issue and I just want to point out that the original behaviour (for Firefox < 62) was not to open a new tab, but to send ctrl+click to the browser and let it handle it (and yes, ctrl+clicking a link opens a new tab, but our issue was with multiselect on custom elements that was handled in javascript).

Hi asmigala,

(In reply to asmigala from comment #1)

I'm one of the people who gave feedback on the original issue and
I just want to point out that the original behaviour (for Firefox
< 62) was not to open a new tab, but to send ctrl+click to the
browser and let it handle it (and yes, ctrl+clicking a link opens
a new tab, but our issue was with multiselect on custom elements
that was handled in javascript).

Yes, thanks for pointing this out. I actually thought about this
distinction after I had left work yesterday. You are entirely
correct.

To that point, I think our mouse synthesiser indeed will not open
a new tab on Control + click, because it blocks any form of interaction
that would transcend into the browser chrome.

Oh, interesting.

Just for context: when I made my comment about Linux two years ago, I had tried it out on a Linux VM on a macos host using testing/web-platform/tests/webdriver/tests/perform_actions/support/test_actions_wdspec.html and I did indeed see a contextmenu event with button 2 being fired. I just opened up that same VM now and I still get a contextmenu! So there must be something different going on in that environment compared to what people have been reporting.

Backed out for wpt failure on actionsWithKeyPressed.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/db9d7fbf94d826f78a95d163db33639ccb56d65f
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=257235016&repo=autoland&lineNumber=3706

James, do you think you could give me some pointers on what we're supposed to do here? It looks like I've made a WPT infra test we expect to fail pass now and I'm not sure what the process is for changing the annotation.

The metadata file is https://searchfox.org/mozilla-central/source/testing/web-platform/meta/infrastructure/testdriver/actions/actionsWithKeyPressed.html.ini I guess it's still failing on mac? So the condition should probably become if os == mac: FAIL. In the specific case of infrastructure tests there's a second metadata file that needs to be updated which we use for upstream CI; that's https://searchfox.org/mozilla-central/source/testing/web-platform/tests/infrastructure/metadata/infrastructure/testdriver/actions/actionsWithKeyPressed.html.ini and you should probably change the condition there to if product == "firefox" and os == mac: FAIL

https://hg.mozilla.org/mozilla-central/rev/899f5fd66315