Affected versions

• Latest Nighty 68.0a1, Beta 67.0b3, Release 66.0

Affected platforms

• All

Steps to reproduce

1. Open Firefox and navigate to a page, ex: https://www.facebook.com/
2. Open a new tab and type "face"
3. From the search suggestions Ctrl+Click on the "Switch to Tab" option

Expected result

• A third tab should open with the https://www.facebook.com/ page, focus should remain on the new tab.

Actual result

• Page is opened in the same tab.

Regression range

• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=eb6516c0e7ef789e0c90742ab4b0011a69394f7b&tochange=6b31860ce71080e89b1e9d63eb9f838b73d54e35
• Potentially regressed by: Bug 237027

Additional notes

• see also Bug 1296366

This is also reproducible on the Quantum Bar

This requires a design decision, the problem is that all of ctrl, alt, shift are considered override keys for switch to tab, that means ctrl/alt/shift+clicking on a switch to tab entry would in practice just override switch to tab, forcing a new load in the current tab.
Making them open in new tab/new window may confuse users expecting them to just override switch to tab.
Making ctrl open in current tab, alt in new tab, shift in new window would still be confusing because ctrl is used in a large chunk of the browser to open in a new tab.
We could make shift open in current tab, ctrl/alt in a new tab, though we'd lose the possibility to open in a new window... it is probably a less expected behavior than opening in a new tab.

Drew, what's your opinion?

I'm not sure we have good options, aside from just doing exactly what awesomebar does (i.e., fixing comment 0, I think?). We could do:

alt: current tab
ctrl: new tab, selected
shift: new window
ctrl+shift: new tab, background

Which is consistent with whereToOpenLink, except it replaces alt's save behavior (which doesn't make sense here) with opening in the current tab: https://searchfox.org/mozilla-central/rev/532e4b94b9e807d157ba8e55034aef05c1196dc9/browser/base/content/utilityOverlay.js#158

But whereToOpenLink isn't consistent with the urlbar's separate modifier handling unfortunately (_whereToOpen): https://searchfox.org/mozilla-central/rev/532e4b94b9e807d157ba8e55034aef05c1196dc9/browser/components/urlbar/UrlbarInput.jsm#1064

In this case, we're talking about selecting/clicking results, not typing in the input, so maybe it would be OK not to be consistent with _whereToOpen.

We should be careful about potentially breaking people's habits. But I wonder how many people ever override switch to tab.

The problem is there are people using alt to open in a new tab with alt+enter, then the mouse and keyboard modifiers wouldn't agree :(

I'm making this a bit more generic to cover both mouse and keyboard.
I'm preparing a document with the current status, from which we can evaluate changes. Will post it when ready.

I put my suggestion in https://docs.google.com/spreadsheets/d/12kvPwX6PAwH5voorJbRmO8Wec_9nvDRW6TsHiiXFXAg/edit?usp=sharing
There will be things to verify and discuss, anyway.

Drew, what's your opinion on my suggested changes? feel free to comment directly in the document.
This would at least be 3 separate bugs, one to change CTRL+SHIFT+Enter, one to make switch-to-tab work the same as normal entries and one to make all opening in tabs coherent with the loadInBackground pref.

We have deliberately not used browser.tabs.loadInBackground for chrome links because the use case is different. E.g. when reading on a web page you might want to open some links in the background to get back to later. This hardly makes sense in the address bar and might irritate users touching that pref (which is exposed in the UI) to optimize their content link work flow.

The proposal is indeed up for evaluation and discussion, and I partially agree with you, consistency may be a win but this is likely the most controversial change, for which I'd leave it as the last thing to evaluate.
Note, there is also bug 1364415 about leaving the popup open when opening in new tabs (similarly we already have a pref for bookmarks menus). And bug 469456 for being consistent in bookmarks views. So in the end the Address Bar may end up being the one acting differently.

Currently I'd mostly like to make action-rows (switch-to-tab) consistent with the normal ones, and maybe address the chrome-parity change (nit).

I left some comments in the spreadsheet. tbh it's hard for me to think about, but the way I do think about it is, content click handling is canonical, and ideally all other handling should be as consistent with it as possible. So I like that you've made urlbar click handling consistent with content click handling. I'd like to then make enter key handling consistent with click handling, except for ctrl.

But I agree that loadInBackground probably shouldn't apply to chrome links, and I'm not 100% sure how that affects that.

(In reply to Marco Bonardo [::mak] from comment #10)

Currently I'd mostly like to make action-rows (switch-to-tab) consistent
with the normal ones, and maybe address the chrome-parity change (nit).

I think these are good goals, if we don't do anything else.

Do we have telemetry on people using modifier keys when clicking and pressing enter? This looks like all we have: https://searchfox.org/mozilla-central/rev/f91bd38732d4a330eba4e780812274b98eb81274/browser/modules/BrowserUsageTelemetry.jsm#664 I'm a little worried about the cost of breaking people's habits.

(In reply to Drew Willcoxon :adw from comment #11)

Do we have telemetry on people using modifier keys when clicking and pressing enter? This looks like all we have: https://searchfox.org/mozilla-central/rev/f91bd38732d4a330eba4e780812274b98eb81274/browser/modules/BrowserUsageTelemetry.jsm#664 I'm a little worried about the cost of breaking people's habits.

Right, that's the big risk, and why we'll probably put canonizing things to an halt until we can make an informed decision, and just concentrate on actual bugs (like this one with switch-to-tab) that are edge cases and already broken, so unlikely to break muscle memory.

I also didn't suggest changing keyboard behavior to be closer to mouse behavior because Chrome copied us on that, so basically we'd break everyone, that is a no-go :(

I don't think we have telemetry about modifiers, anyway.

While this is being worked on, would it be possible to include the dropdown menu on Mac too? Just tried Chrome and Safari. Chrome does allow you to use Command to open in a new tab, but it’s always the foreground tab (shift does nothing). Safari actually goes all the way and has the same keys allowed as a link on the page, a link in the bookmarks bar, and in the menu. In Safari I can open the History dropdown, and use both Cmd and Cmd+Shift to open in the background and foreground tab.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

I realize no final decision has been made yet, but just in case it's useful I've implemented the logic from comment 3. It only modifies the behavior for clicks.

The bug assignee didn't login in Bugzilla in the last 7 months.
:adw, could you have a look please?
For more information, please visit auto_nag documentation.

As previously discussed, this should likely be converted into a proposal. There's risk to break muscle memory, so the work could be reduced, for example handling only switch to tab entries.
Though there's also the possibility to re-evaluate switch-to-tab to either use the new result menu or a sub-button to allow reopening a tab, instead of relying on invisible override modifiers (shift/alt/ctrl) and then those could work properly, like on other results.