74.71 KB, image/png
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.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Component: Location Bar → Search
Resolution: --- → DUPLICATE
Duplicate of bug: 344381
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<.
Status: RESOLVED → REOPENED
Component: Search → Location Bar
Ever confirmed: true
Resolution: DUPLICATE → ---
I think it should have a new preference instead of changing the original behavior.
Status: REOPENED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Summary: browser.search.openintab set to true URLs typed open in new tab → URLs be open in new tab when browser.search.openintab set to true
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.
Hi Marco, should we reconsider introduce a new pref for this?
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.
Flags: needinfo?(mak77) → needinfo?(past)
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.
> 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.
Edit: "that this breaks" -> this bug, not this comment
Bug 1394304 has been backed-out. Mark this as fixed.
Status: NEW → RESOLVED
Closed: 2 years ago → 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.