Bugzilla

(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](#c0) 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
 4. opening a tab in background keeps the menu open regardless of how the tab was opened in background (modifier, or `openInTab`)
5. 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.

>     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.

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.

(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](#c0) 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
 4. opening a tab in background keeps the menu open regardless of how the tab was opened in background (modifier, or `openInTab`)
5. 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.