1753863 - Extend the urlbar & searchbar's ability to open results in background tabs

Status: ASSIGNED

(Firefox :: Address Bar, task, P3)

Description

[Shane Hughes [:aminomancer]]

The goal of this task is to make it easier for users to open background tabs from the urlbar and searchbar. Users can already do this to some extent using keyboard modifiers, but the implementation is a little inconsistent, and the popup is still closed when activating a result, which partially defeats the purpose. So this has two interrelated aspects:

1. Stop the urlbar/searchbar popup from hiding when navigation creates a new background tab.
2. Add new prefs that make new tabs opened from the urlbar/searchbar "background" tabs.

These are the 2 new prefs I have in mind:

browser.urlbar.openinbackground
browser.search.openinbackground

They will work in concert with these existing prefs:

browser.urlbar.openintab
browser.search.openintab

openintab and openinbackground work similarly to these existing prefs:

browser.tabs.loadBookmarksInTabs
browser.tabs.loadBookmarksInBackground

This results in the following possible interactions for urlbar and searchbar results:

1. Default state (both prefs false)
   1. current = Left click or Enter
   2. new active tab = Ctrl + left click, Alt + Enter, or middle click
   3. new background tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
2. browser.urlbar.openinbackground = true
   1. current = Left click or Enter
   2. new active tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
   3. new background tab = Ctrl + left click, Alt + Enter, or middle click
3. browser.urlbar.openintab = true
   1. current = Ctrl + left click, Alt + Enter, or middle click
   2. new active tab = Left click or Enter
   3. new background tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
4. browser.urlbar.openinbackground and browser.urlbar.openintab = true
   1. current = Ctrl + left click, Alt + Enter, or middle click
   2. new active tab = Ctrl + Shift + left click, Shift + Alt + Enter, or Shift + middle click
   3. new background tab = Left click or Enter

It also affects how one-off search buttons work, but in a slightly different way. The default state for one-offs is to set the search mode, not perform any navigation. So the above information is all the same for one-offs, except that instead of current, we set the search mode.

There is a lot of other minutiae as well. If there's no search string then it doesn't matter what the settings are, clicking a one-off search button always sets search mode. Similarly, if a "local" search engine button is selected (e.g., bookmarks, history, open tabs), we set the search mode instead of opening a tab.

An open question is what we should do with the results, the user input, and the search mode when we select a result in such a way that it opens in a background tab. Prior to this task that wasn't a problem since the popup always closed. But now that the popup stays open, we have to ask what will happen to the input string, results, and search mode (i.e., the indicator).

When you cycle through results with arrow keys, it changes the input string to the result's url or search string, but without starting a new query. So my thinking is that when you click a result and it opens in the background, since it selects the result, it should change the input string but without starting a new query. When you use the Enter key to open a result in a background tab, typing or arrow keying through results will have already set your search string so there's no reason to set it at all.

However, if you click a one-off search button, it needs to set the search mode, so it needs to update results.

We need to change some javascript in a variety of places to avoid minor bugs e.g. when clicking a one-off button with an empty string, typing in a string, then clicking a different one-off button.

Finally, there might be justification for adding a third pref, browser.tabs.reuseEmptyTab because users who go to the trouble of making background tabs the default for the urlbar or searchbar may have a variety of rationales. So always reusing an empty tab no matter what may not be desirable for everyone.

Comment 1

[Shane Hughes [:aminomancer]]

A separate but related issue would be adding a test for browser.search.openintab similar to the existing test for browser.urlbar.openintab. I'm working on expanding the latter test to deal with these changes and browser.urlbar.openinbackground but I guess the search pref tests might be a different bug to avoid making this patch too big.

Edit: Never mind, the search test is included in this patch. I still haven't included browser.tabs.reuseEmptyTab since it might be seen as outside the scope of this bug. However, it does impact most of the same files (including the 2 test files) so adding it here might save some time

Comment 2

[Shane Hughes [:aminomancer]]

Attachment: Bug 1753863 - Extend url/searchbar background tab features. r=adw,mak

The goal of this task is to make it easier for users to open background tabs from the urlbar and searchbar. Users can already do this to some extent using keyboard modifiers, but the implementation is a little inconsistent, and the popup is still closed when activating a result, which partially defeats the purpose. So this has two interrelated aspects:

1. Stop the urlbar/searchbar popup from hiding when navigation creates a new background tab.
2. Add new prefs that make new tabs opened from the urlbar/searchbar "background" tabs.

This also updates the documentation for the relevant prefs. I think I will complete the test coverage in a separate bug. This updates a test for the urlbar, but as there is no existing test for browser.search.openintab I'm going to need to make a new one for the searchbar changes.

Comment 3

[Marco Bonardo [:mak]]

This is a non-trivial change with associated risks. Is it part of a planned frontend project, or did you decide to work on this on your own?
I totally respect this will of contributing, but before undertaking such a large rewrite, you should plan with the frontend team and agree upon how to do it. Otherwise the risk is that it will stay in a limbo for a long time, because people may not have enough time to review and ensure this is safe enough for landing. That is pretty much the problem with Bug 1673588.
Taking small incremental fixes is easy, taking large rewrites of user interaction is not. The risk is you doing a lot of work and nobody able to pick it up in a short time frame.
Most new features should also be developed behind a pref, so that we ca neasily switch Release to the previous behavior, in case severe regressions are found.

There's a lot of things to go through, including bug 1536756.
I think this requires a complete analysis and breakdown to try to tackle problems one at a time and reduce the risks.

This is an apparently easy problem, but very complex in practice when keeping into account all the possible combinations, coherency with the other UI views, and will of keeping things simple (not 100 different prefs generating infinite combinations to test).
Mixing up multiple behavioral changes and re-architecture into a single bug is unlikely going to work if we want to mitigate risks and complexity.

Comment 4

[Shane Hughes [:aminomancer]]

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

This is a non-trivial change with associated risks. Is it part of a planned frontend project, or did you decide to work on this on your own?

Thanks for the feedback. I certainly didn't intend to give the impression that I thought this was a trivial change without any risks. I have been trying to track down every implication of the current usability problems and every implication of the proposed changes. As for my motivation, someone just asked on my gh page if I am willing to make a user script for them to the tune of bug 1673588.

I did some research and got the impression from your posts in the other bugs that there was already general agreement, and specific details could be worked out in review, as with the older patch. I just made a new bug because I didn't wanna hijack someone else's, and I thought this would likely involve multiple bugs, so a task was more suitable.

Taking small incremental fixes is easy, taking large rewrites of user interaction is not. The risk is you doing a lot of work and nobody able to pick it up in a short time frame.

I guess I didn't really see this as a large rewrite. It involves a bit of redundancy because the same behavior was already duplicated in several places, so I had to update it everywhere. I considered turning _whereToOpen into a shared helper function, but I didn't want to clutter the patch with unnecessary or tangential changes.

Well if you test the patch let me know what you think. I can separate the popup change and pref change into 2 patches now. It was a lot easier to work on them at the same time because it's tedious to test 1 without the other. I don't think this is really a major new feature compared to the other patches I worked on, since all the keyboard shortcuts already existed. I just tied them to preferences in the same way as the existing bookmarks prefs.

This is an apparently easy problem, but very complex in practice when keeping into account all the possible combinations, coherency with the other UI views, and will of keeping things simple

I didn't think this was an easy problem - I did spend time tracking down all the possible permutations of prefs and shortcuts before writing a patch. Consistency with the other UI views was my main reason for doing it this way (e.g., see the bookmarks prefs).

(not 100 different prefs generating infinite combinations to test).

In this case I added 2 new prefs, and only because there are already 2 existing openintab prefs. If it wasn't that way from the start I would have made a single openintab pref and a single openinbackground pref for both urlbar and searchbar. And consolidating them into 1 might be worthwhile, but rolling that into this patch would only make it even bigger.

There's a lot of things to go through, including bug 1536756.

Bug 1536756 doesn't seem like a blocking issue, since this patch doesn't change the keyboard shortcuts themselves, it just adds a new pref that reverses tab and tabshifted and holds popups open in one condition. Bug 1753878 would change the actual key combinations so it would need to be coordinated with any changes to action override feature. But the key combos are the same in this patch, and I think the refactoring of the _whereToOpen methods in this patch will actually make resolving those bugs easier.

I totally respect this will of contributing, but before undertaking such a large rewrite, you should plan with the frontend team and agree upon how to do it. Otherwise the risk is that it will stay in a limbo for a long time, because people may not have enough time to review and ensure this is safe enough for landing. That is pretty much the problem with Bug 1673588.

That's fine with me, I'm happy to take any and all feedback and collaborate with anyone. That is my intention in posting this bug. I was going to make a patch anyway so that I could test these settings and get a sense of the experience for myself. At least for me, it's easier if it's not all in my imagination.

Most new features should also be developed behind a pref, so that we ca neasily switch Release to the previous behavior, in case severe regressions are found.

One of the 2 changes is the addition of new prefs, so it didn't make sense to me to lock the new prefs behind an experimental pref. However, I guess that's feasible. The popup changes could also go behind a pref, but those are such minor changes. In any case, I don't think it's a good reason to go back to the drawing board.

I think this requires a complete analysis and breakdown to try to tackle problems one at a time and reduce the risks.
Mixing up multiple behavioral changes and re-architecture into a single bug is unlikely going to work if we want to mitigate risks and complexity.

I'm just trying to help move things forward. If there's a specific path forward you want to take, I'll certainly follow. I don't know of any other bugs that the popup change really depends on. The patch has solid test coverage. Breaking it up into smaller pieces would be a practical way to simplify this.

Comment 5

[Marco Bonardo [:mak]]

User behavioral changes are usually behind a pref, because there's always the possibility they introduce regressionsand we have to revert the change until those concerns are resolved. Flipping a pref is much easier than merging backouts. In this case, it's possibly not necessary, because ideally if the new prefs are not flipped, nothing should change from the status-quo. But that requires QA to ensure it's true, and landing a large patch changing all at once complicates things.

Long term, the search bar and urlbar should converge in behavior, both openInTab prefs are also hooked into web-ext, should the new prefs be hooked up too? I'm not 100% sure, and I'd probably suggest to first merge them. That would also require checking how many web-ext are using these browserSettings values effectively.
Also the pref name, we have existing .loadInBackground prefs, that suggests this new pref should also be named after those, that allows users to find all releted prefs more easily.

Then, of course, there's the modifier key that allows to switch the behavior on the fly, for example while ctrl+click on Windows allows to open in a new tab, ctrl+shift+click opens the tab in background. This may suggest a first good step may be to keep open the panel when we already open in background with the modifier. The modifier of coure complicates the matrix of cases to consider and inverts the behavior of the loadInBackground pref. This is even more complex for search shortcut buttons and switch-to-tab entries, where shift has a different meaning, that should also be analyzed.

Summing up, I think the main problem is splitting the work into smaller incremental patches that can be landed and verified separately.
Those may include keeping the panel open when loading in background using the modifier (no new prefs required, mostly ensuring things around opening in background work), cleaning up the whereToOpen code so later changes are easier to make, figuring out how many webExt are using browserSettings for the current prefs and evaluate merging those prefs into one, introducing the new loadInBackground pref with tests covering behavior with and without the modifier and different kind of results (normal, switch to tab, search shortcut), that will uncover coherence bugs that must have a plan of action, even if it's long term (bug 1536756, bug 1753878).

Comment 6

[Shane Hughes [:aminomancer]]

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

Long term, the search bar and urlbar should converge in behavior, both openInTab prefs are also hooked into web-ext, should the new prefs be hooked up too? I'm not 100% sure, and I'd probably suggest to first merge them. That would also require checking how many web-ext are using these browserSettings values effectively.

Thanks for the advice. I can't say I know how to investigate addon usage, but if you can point me in the right direction I'm happy to try. Merging the urlbar & searchbar prefs seems like a worthy goal and the background prefs don't seem as urgent as the popup behavior or making the existing "where to open" behavior consistent across views. So I will make separate bugs for those and assume that background prefs can't be resolved quickly.

Also the pref name, we have existing .loadInBackground prefs, that suggests this new pref should also be named after those, that allows users to find all releted prefs more easily.

Yeah that does make sense — my original intention was browser.urlbar.loadInBackground but when I started adding the same for search, I noticed there's a pref browser.search.context.loadInBackground and thought this might confuse users. But I guess that pref only exists because there wasn't already a browser.search.loadInBackground to use for that purpose. So maybe they could be merged as well. Another question regarding prefs is, assuming we merge urlbar and search prefs, what the branch name should be.

Then, of course, there's the modifier key that allows to switch the behavior on the fly, for example while ctrl+click on Windows allows to open in a new tab, ctrl+shift+click opens the tab in background. This may suggest a first good step may be to keep open the panel when we already open in background with the modifier. The modifier of coure complicates the matrix of cases to consider and inverts the behavior of the loadInBackground pref. This is even more complex for search shortcut buttons and switch-to-tab entries, where shift has a different meaning, that should also be analyzed.

Yes it is pretty complex, but I already accounted for one-off search buttons, tab to search results, and each modifier including the existing tabshifted behavior. I spent a while working on this so I tried several options, but I think the one reflected in the current patch has the least impact on the current default experience. I believe I tested every urlbar provider, including switch-to-tab.

With switch-to-tab results, behavior is not affected by the existing openintab pref, and I wouldn't expect the background pref to affect it either, as it only swaps tab and tabshifted behavior. That is, it's not possible to ctrl+click on a switch-to-tab result due to the action override feature. The only scenario where it would impact behavior is when openintab and openinbackground are both enabled. But that's kind of outside the scope of these changes since it would involve changing the existing behavior for openintab.

In this case, unmodified Enter/click just switches to the tab, which is true irrespective of prefs. And any modifier just changes it to load the URL in the current tab. But that's the same as when any or none of the prefs are enabled. So it doesn't break anything, the question I have is whether it should behave differently. But I don't think that has anything to do with the prefs, because even now, there is no way to open a switch-to-tab result in a new tab or new window. So it already ignores existing modifiers, and adding the pref wouldn't affect that.

If we follow through on bug 1753878, I think a clean solution to the lack of options for switch-to-tab results would be to restrict the action override behavior to the Alt key, just like the canonization behavior. That is, consolidate them into one contextually defined behavior (see bug 1754439). A switch-to-tab result can't be canonizable, so they aren't stepping on each other. Moreover, I think to make the canonization behavior more obvious (less surprising), we should add some kind of visual indication that the search string is going to be canonized. So by that I mean, treat canonization and "action override" as one thing.

If user presses the Alt key that enables a contextual "alternative" behavior. In the case of switch-to-tab results, that means opening the URL in question in the current tab (and possibly add further Shift and Accel modifiers to allow opening it in a new window or tab instead). And visually, that will be indicated by the "Switch to Tab" action label being replaced with the URL. In the case of regular search results, that means turning the search string into a URL. And visually, that could be indicated by either the search string or the "Search with x" action label being replaced by the canonized URL, with the search string characters highlighted in the URL.

I think that's a separate issue from the load in background thing, but I can make another bug for that (depending on bug 1753878) if you think it's a good idea.

Summing up, I think the main problem is splitting the work into smaller incremental patches that can be landed and verified separately.
Those may include keeping the panel open when loading in background using the modifier (no new prefs required, mostly ensuring things around opening in background work), cleaning up the whereToOpen code so later changes are easier to make, figuring out how many webExt are using browserSettings for the current prefs and evaluate merging those prefs into one, introducing the new loadInBackground pref with tests covering behavior with and without the modifier and different kind of results (normal, switch to tab, search shortcut), that will uncover coherence bugs that must have a plan of action, even if it's long term (bug 1536756, bug 1753878).

I think if we are gonna test the outcome of specific result types for a set of modifier/pref combinations, we have to do the same with openintab since it has a more dramatic effect for the typical use case I think (unmodified left click/Enter). Does that sound right? I tested for every possible pref and keyboard modifier combination in the test in this patch, but I did it in the same manner as the existing openintab test. So it's not very sophisticated, it only checks where a result should be opened, not where it actually opens. And neither test validates the one-off search button behavior.

Comment 7

[Shane Hughes [:aminomancer]]

I'm working on bug 1754427 and I've come across another potential enhancement. For dynamic calculator results, on Shift+Alt+Enter I think we want to keep the view open and avoid reverting the search string. Otherwise it feels kind of awkward that it's just ignoring the modifiers completely. And it makes sense that a user might want to hold the view open so they can, say, copy 4+4 and then type + and Accel+V to get 4+4+8 or something like that. Being able to quickly feed back into the original expression might be useful.

However, this creates a dilemma where there isn't any visual feedback if you activate a calculator result while holding the background modifiers (Shift+Alt+Enter/Shift+Accel+Click). So it may not be obvious that anything even happened. In some of my custom scripts I've used the ConfirmationHint to display a Copied! message. I think displaying a brief hint like that, anchored to the result that was copied, would be useful for background activations of results that don't navigate. So that could also apply to other dynamic result providers added in the future.

Any opinions?

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 9

[Suhaib Mujahid [:suhaib]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Comment 10

[Shane Hughes [:aminomancer]]

I'm free to take another crack at this, though there are still some unanswered questions:

1. Should we add new prefs like I described in comment 0 so that users can open tabs from the urlbar in the background by default? standard8 expressed some hesitation about adding new prefs. My original impetus for reporting this was a user messaged me requesting some kind of extension to modify how the urlbar works, so they could make opening tabs in the background the default action. But that is admittedly a pretty marginal use case.

   Last time we discussed it, Marco suggested only adding a single new pref, since the long-term plan is to unify urlbar and searchbar behaviors. So, ideally, the urlbar and searchbar would behave exactly the same and be controlled by the same prefs. Currently that's not the case for the openintab prefs, but it would probably be better not to add to the problem by adding separate openinbackground/loadInBackground prefs for urlbar and searchbar.

2. Should we do bug 1753878? It's not necessary for the completion of this bug, but it would help make the behavior more consistent between urlbar and searchbar, and make having separate prefs for these features less important.

3. Most of the features that open new tabs instead load the URL in the current tab if the selected browser is currently empty, e.g. new tab or about:blank or something. This can be a problem for the use case this "loading tabs in background from the urlbar" feature is intended to accommodate. The main interest in this feature, I think, is the desire to be able to open a whole bunch of results rapidly.

   So let's say you open a new tab and you're about to try to do that. But since you're on your new tab page, the selected browser is empty. So when you're about to click a bunch of results, the urlbarview immediately closes on the first click because of the reuseEmpty feature. Then you have to open the urlbarview again now that it's no longer empty, and then you can start.

   Of course that's how it's supposed to be, and eventually user will get used to it. But given that this patch will allow users to essentially open background tabs by default (e.g. with left click or Enter), I think it may become an irritant. So I think it may also be useful to add an additional preference browser.tabs.reuseEmptyTab that disables this.

Comment 11

[Marco Bonardo [:mak]]

(In reply to Shane Hughes [:aminomancer] from comment #10)

I'm free to take another crack at this, though there are still some unanswered questions:

Thank you, the problem is we need a person from the Search team with time to mentor the change (not you specifically, cause I know you're good at coding, but these changes are still risky, so they require particular attention and time). Unfortunately I don't think I have enough time.
I'll try asking in the search channel if anyone thinks they can find some time soon.

1. Should we add new prefs like I described in comment 0 so that users can open tabs from the urlbar in the background by default?

Probably the safer path forward would be to add a featureGate pref, something like browser.urlbar.openInBackgroundTabs.featureGate, that can be removed once the feature is stable...
When browser.urlbar.openInBackgroundTabs.featureGate is set:

1. both the urlbar and searchbar just respect browser.urlbar.openintab
2. a new browser.urlbar.loadTabsInBackground pref controls the new tabs behavior, if set to true tabs are opened in background by default, the key modifier inverts its behavior
3. opening a tab in background keeps the menu open regardless of how the tab was opened in background (modifier, or openInTab)
4. this means one has to set loadTabsInBackground for the menu to stay open. openInTab is just an indication of the default click behavior but won't modify the panel behavior.

When the featureGate pref is false or unset, things keep working like today.

2. Should we do bug 1753878? It's not necessary for the completion of this bug, but it would help make the behavior more consistent between urlbar and searchbar, and make having separate prefs for these features less important.

Probably not, that's something to evaluate in the future. I also think we should for example remove shift/alt/ctrl being override keys for certain results (like switch to tab) since they are undiscoverable, and there's other things to consider... So I'd not scope-creep.

3. Most of the features that open new tabs instead load the URL in the current tab if the selected browser is currently empty

Based on what I said about needing loadTabsInBackground for the menu to stay open, is is actually a problem to reuse an empty tab?

Regarding why I'd not want a default state where you can just click on things and the menu stays open: it's too risky, it may lock up the user into that state, may have privacy implications (over the shoulder observer), and no other browser is doing that, so it may suprise the user in some negative way... it's also something that could still happen on top of the rest in the future, so we're not closing any path forward.

Comment 12

[Shane Hughes [:aminomancer]]

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

Thank you, the problem is we need a person from the Search team with time to mentor the change (not you specifically, cause I know you're good at coding, but these changes are still risky, so they require particular attention and time). Unfortunately I don't think I have enough time.
I'll try asking in the search channel if anyone thinks they can find some time soon.

Sounds good, thanks! No rush or anything, just figured I'd post a more concise update about the status and issues, so these kinds of design decisions can be made.

Just to be clear, about your point #4 that one has to set loadTabsInBackground for the menu to stay open: We already have the ability to Shift+Accel+click a urlbar result to make it open in a background tab. The problem is just that doing so unnecessarily closes the urlbar view. So, are you proposing that we just don't apply this new panel behavior to that case, where the result is loaded in a background tab solely because both modifiers were pressed? And then the new panel behavior only applies if the loadTabsInBackground pref is set?

Based on what I said about needing loadTabsInBackground for the menu to stay open, is is actually a problem to reuse an empty tab?

Do you mean if loadTabsInBackground is set, we make the menu stay open when reusing an empty tab? Otherwise, it still seems like the reuseEmpty behavior interferes with the use case of opening a bunch of tabs from the urlbar. But in retrospect I think maybe I have been a bit too nonchalant about adding new prefs. Having a better understanding of the testing costs, I would be less trigger-happy on adding a pref for such a narrow purpose. But I still think it'd be nice to resolve that problem somehow. Maybe the best approach is to keep the menu open when reusing an empty tab, if loadTabsInBackground is enabled and openInTab is set or the equivalent modifier is pressed (I think it's technically a bit complicated, but doable). There could be other solutions, but I can't think of anything at the moment.

Comment 13

[avada]

(In reply to Shane Hughes [:aminomancer] from comment #10)

I'm free to take another crack at this, though there are still some unanswered questions:

1. Should we add new prefs like I described in comment 0 so that users can open tabs from the urlbar in the background by default? standard8 expressed some hesitation about adding new prefs. My original impetus for reporting this was a user messaged me requesting some kind of extension to modify how the urlbar works, so they could make opening tabs in the background the default action. But that is admittedly a pretty marginal use case.

I'm quite sure I (as the person who brought this up) was only suggesting for tabs to be opened in the background (with the urlbar/results preserving state of course) when a typical "open in new tab" action was performed. Middle+click, ctrl+LMB, alt+enter (if the modifier stays as it is).
Opening in a new (background or not) tab via mere left click or enter would be unusual and unexpected.

Comment 14

[Shane Hughes [:aminomancer]]

(In reply to avada from comment #13)

I'm quite sure I (as the person who brought this up) was only suggesting for tabs to be opened in the background (with the urlbar/results preserving state of course) when a typical "open in new tab" action was performed. Middle+click, ctrl+LMB, alt+enter (if the modifier stays as it is).
Opening in a new (background or not) tab via mere left click or enter would be unusual and unexpected.

I mean the default action when opening tabs, not the default action when clicking urlbar results (see comment 0). There's no need for new prefs to make opening in tabs the default, as the pref browser.urlbar.openintab already exists (along with an equivalent for the searchbar). Urlbar results can be opened in tabs by two methods - 1) the pref, and 2) a modifier (Ctrl/Cmd for click, Alt for Enter). The question is whether we add a new pref that makes these tabs open in the background by default (as opposed to requiring an additional modifier, as is currently required).

Unless I'm misunderstanding, your request is to make urlbar results opened by the "open in tab" modifier load in background tabs instead of foreground tabs, without requiring an additional modifier (Shift). Which I don't think is a desirable default (most users will expect Ctrl+click or middle click to open foreground tabs), so fulfilling that request would require a new user preference.

Comment 15

[Marco Bonardo [:mak]]

(In reply to Shane Hughes [:aminomancer] from comment #12)

Just to be clear, about your point #4 that one has to set loadTabsInBackground for the menu to stay open: We already have the ability to Shift+Accel+click a urlbar result to make it open in a background tab. The problem is just that doing so unnecessarily closes the urlbar view.

No, as I said in point 3, IFF browser.urlbar.openInBackgroundTabs.featureGate is true, then any opening in the background will keep the panel open.
Point 4 just meant openInTab alone won't keep the panel open, one will also have to set loadTabsInBackground for it to keep the panel open.

Do you mean if loadTabsInBackground is set, we make the menu stay open when reusing an empty tab?

Yes, unless there's technical reasons to not do that.