1396059 - URLs be open in new tab when browser.search.openintab set to true

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[matthias koplenig [:metasieben]]

STR
1) set >browser.search.openintab< to >true<
2) open about:newtab / focus urlbar
3) input URL and press ENTER

result:
*) URL opens in new tab

expected result:
*) URL should replace the empty new tab


clicking the GO-button does work as expected,
as does choosing any URL in the history-dropdown with the mouse.

Comment 2

[matthias koplenig [:metasieben]]

i'm not sure that this is a dupe of bug 344381.

why is any input with the keyboard treated differently than the mouse?
also this seems to have regressed/changed yesterday/today.

it looks to me like any urlbar-input with a keyboard is treated like a search,
although the first-entry in the dropdown says >Visit<.

Comment 3

[matthias koplenig [:metasieben]]

Attachment: urlbar highlights a domain, will perform a >search<

Comment 4

[YF (Yang)]

I think it should have a new preference instead of changing the original behavior.

Comment 5

[Albert Scheiner [:alberts]]

I thought something was broken, when suddenly each time I _reused_ a tab by typing a URL and hitting enter yet a _new_ tab opened _at the end of all my tabs_ (so maybe 20 tabs away from where I just hit enter). Worse, even when I just focus the URL in order to reload the tab and hit enter it duplicates the tab.
A new pref as YF suggests would be very desirable.

Comment 6

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Hi Marco, should we reconsider introduce a new pref for this?

Comment 7

[Marco Bonardo [:mak]]

Maybe we should condition the behavior to whether the search bar is being used or not? Or maybe it should only affect search suggestions...
The fact is that once the search bar is removed in favor of a unified urlbar, users who used this pref will continue finding the expected behavior of opening in a new tab also in the location bar. Introducing a new pref will require setting again the preferred behavior.
It's a classical situation where it's complicate to satisfy everyone.

Changing the behavior or the pref here is trivial, and it's worth collecting feedback about both approaches.
Panos, how do you think we should move (should we involve UX)?

The options I see are:
1. split the prefs (fix mouse so it's consistent), and lose transparent migration of the behavior from search bar to location bar
2. keep the single pref so users can migrate easily to unified location bar but make it apply only to search-like results
3. keep the single pref so users can migrate easily to unified location bar but make it apply only if search bar is gone

Off-hand I'd probably go for 2, but even 1 is a possibility if we don't care.

In any case I think we should make mouse actions consistent with the keyboard.

Comment 8

[Marco Bonardo [:mak]]

We are backing out the change, then we'll mark this as fixed.

The evaluation of the approach will continue in the original bug, once reopened.

Comment 9

[David Smith]

> The fact is that once the search bar is removed in favor of a unified urlbar, users who used this pref will continue finding the expected behavior of opening in a new tab also in the location bar. Introducing a new pref will require setting again the preferred behavior.

Just a note, that this breaks even being able to just edit the URL without spawning a new tab.  If it *only* spawned a new tab on a search (as a replacement for the search bar), it would be appropriate to tie it to the same pref.  But there are too many non-search-related cases that it's interfering with that should have a different pref.

Comment 10

[David Smith]

Edit: "that this breaks" -> this bug, not this comment

Comment 11

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Bug 1394304 has been backed-out. Mark this as fixed.