1439728 - AwesomeBar forcing switch to existing tab for the heuristic entry

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[(No longer employed by Mozilla) Aaron Klotz]

I started noticing this yesterday but I am not sure which Nightly build I was running at the time.

STR:
1. Open a tab, point it to reddit.com/r/firefox
2. Open a second tab, type reddit.com/r/firefox

Expected:
The top entry in the AwesomeBar is "Visit," and when I press enter the tab loads a new instance of reddit.com/r/firefox

Actual:
There is no "Visit" entry. The top entry is the existing /r/firefox tab, and thus pressing enter sends me to the previous tab. It is not possible to direct a new tab to a new instance of a website that is already open in another tab.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

Oddly enough, I don't seem to be able to reproduce this with other URLs...

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

Correction: It looks like I can reproduce it with any URLs whose tabs I had open prior to whichever update caused this regression. Was there a schema update or something?

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Aaron Klotz [:aklotz] from comment #2)
> Correction: It looks like I can reproduce it with any URLs whose tabs I had
> open prior to whichever update caused this regression. Was there a schema
> update or something?

Actually, the affected tabs were also bookmarked.

Comment 4

[Marco Bonardo [:mak]]

We partially fixed bug 1222435, that allows the autofill entry to switch to an already open tab.

Comment 5

[Marco Bonardo [:mak]]

you should be able to ovveride switch to tab as usual, by pressing shift.

Comment 6

[Marco Bonardo [:mak]]

(In reply to Aaron Klotz [:aklotz] from comment #3)
> Actually, the affected tabs were also bookmarked.

it doesn't matter, what matters is that the autofilled url is IDENTICAL to one already open. in the future it could be a little bit more lenient (maybe ignoring www and casing)

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

OK, shift is working. This seems like a very opinionated change, though. :-(

Comment 8

[Marco Bonardo [:mak]]

we always prioritized open tabs VS history in the Address Bar, this just continues towards that direction.

Comment 9

[(No longer employed by Mozilla) Aaron Klotz]

But I'm not trying to enter either history or existing tabs, I'm trying to open a new tab.

Comment 10

[(No longer employed by Mozilla) Aaron Klotz]

In other words, why are history and open tabs being prioritized over "Visit", which is the default action of the enter key for a location bar since the beginning of browsers?

Comment 11

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Screenshot

Here's a screenshot.

Notice that there is no Visit entry, just history and open tabs.

If I clear the trailing slash, then the Visit entry comes back.

There's no visual cue as to how the user can open a new tab with that URL. The only way that it works is to clear the slash or hold shift.

Comment 12

[Marco Bonardo [:mak]]

The screenshot is taken holding the shift key I assume, that's how the override is shown usually, like a normal history entry.
Shift just converts a switch-to-tab action to a normal visit. In this case it could probably have a "- Visit" suffix because the url is visible already in the input field. That's a polish bug.

Removing the slash changes things because bug 1222435 is not completely fixed, we should ignore the trailing slash when comparing.
It should still suggest to switch.

(In reply to Aaron Klotz [:aklotz] from comment #10)
> In other words, why are history and open tabs being prioritized over
> "Visit", which is the default action of the enter key for a location bar
> since the beginning of browsers?

Because Firefox has always been a good tab manager (well probably now a bit less without Panorama, but we still have decent tools) and we are more likely to have users with many tabs. Due to that, it's easy for our users to lose track of open tabs and the Address Bar helps with that. This was decided in the past with UX. We can eventually trigger a new discussion to see if anything changed in how our users use the browser.
Clearly it's not always correct to switch to an already open tab, and that's why we support the override and have bug 631671 to track a blacklist.
Also, if you are not liking the switch to tab entries, there's an option in Preferences / Privacy to stop suggesting open tabs in the Address Bar.
We have quite a few options to opt-out.

Comment 13

[Marco Bonardo [:mak]]

Eric, do we want to revisit the switch to tab priority over opening a new tab for the autofill case?
That's basically when the user is typing a url, we autofill to an url that is already open in another tab. We usually didn't switch, because of a bug, we fixed that bug now, but it would be nice to have a second opinion.
See Comment 10 and Comment 12 for arguments.

Comment 15

[Marco Bonardo [:mak]]

Just to report bug 1440944, switch to tab also happens if you paste an url that is already open in another tab and confirm with enter (also in this case, the popup tells that we'll switch and can be overridden with shift)

Comment 16

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to Marco Bonardo [::mak] from comment #12)
> The screenshot is taken holding the shift key I assume, that's how the
> override is shown usually, like a normal history entry.

Oh, that's because I used Alt+PrintSc to take the screenshot.

Comment 17

[Marco Bonardo [:mak]]

yep, alt is another override key.

Comment 18

[Eric Pang [:epang] UX]

(In reply to Marco Bonardo [::mak] from comment #13)
> Eric, do we want to revisit the switch to tab priority over opening a new
> tab for the autofill case?
> That's basically when the user is typing a url, we autofill to an url that
> is already open in another tab. We usually didn't switch, because of a bug,
> we fixed that bug now, but it would be nice to have a second opinion.
> See Comment 10 and Comment 12 for arguments.


From a tab management perspective switching to tab is great..

But IMO I don't think we should switch to tab unless the user chooses the option in the drop down.
I feel the expectation is for the site to open on the current tab by default.  

Also, using shift + enter is too hidden.  It might be a edge case but if a user needs to open the same page twice I can see them getting frustrated and not discovering shift + enter.    

Having 'switch to tab' in the drop down allows both cases to have more visibility.
Would it be possible to move the 'switch to tab' result up to the second result if it's known that the tab is already open?

Comment 19

[Eric Rescorla (:ekr)]

"From a tab management perspective switching to tab is great.."

I'm not sure I agree with this, but it's not great when you are in a different window.

Comment 20

[Marco Bonardo [:mak]]

(In reply to Eric Pang [:epang] UX from comment #18)
> But IMO I don't think we should switch to tab unless the user chooses the
> option in the drop down.

Ok, this clarifies the behavior.

> Also, using shift + enter is too hidden.  It might be a edge case but if a
> user needs to open the same page twice I can see them getting frustrated and
> not discovering shift + enter.    

True, we have both Shift and Alt as "override" keys, but nothing tells that to the user. Could we maybe change the action from "--switch to tab" to "-- Switch to tab (Hold shift to open here)"? That would be self documenting.
(setting a new new needinfo for this question, sorry, but likely this won't make 60 for the string freeze)

> Would it be possible to move the 'switch to tab' result up to the second
> result if it's known that the tab is already open?

Probably, it will complicate the code a bit, but also not switching will complicate the code because it's an exception to the normal rule. I must check what I can do.

Comment 21

[Marco Bonardo [:mak]]

ops I forgot the ni, please check the question about changing the string, in comment 20. Anyway, It will have to happen in a separate bug.

Comment 22

[Eric Pang [:epang] UX]

(In reply to Marco Bonardo [::mak] from comment #21)
> ops I forgot the ni, please check the question about changing the string, in
> comment 20. Anyway, It will have to happen in a separate bug.

no problem! I still worry that users will miss this functionality (shift+enter to open on current tab).  A common interaction is to press enter (sometimes without looking at the drop down at all). The expectation will be for the site to open on the current tab.

Ideally we keep the default as 'Visit' and have the 'Switch to tab' option directly below.  This will give users the interaction they expect while still having a way to switch to tab if that's what they want.

Comment 23

[Marco Bonardo [:mak]]

I'm sorry, I think I didn't express well my question.
For the autofill case (type/paste something and Enter) it's clear that we want separate entries. That's what I'll do here.

I'm instead asking if we should change the action string for the _other_ entries in the popup, the ones the user has to select explicitly, where we won't have a dupe entry, but only the switch to tab one.

Comment 24

[Marco Bonardo [:mak]]

This is  new behavior in Firefox 60, and as such we should track this bug for an uplift.

Comment 25

[Marco Bonardo [:mak]]

Attachment: Bug 1439728 - Don't force a switch-to-tab for the Address Bar heuristic match.

Review commit: https://reviewboard.mozilla.org/r/226478/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/226478/

Comment 26

[Eric Pang [:epang] UX]

(In reply to Marco Bonardo [::mak] from comment #23)
> I'm sorry, I think I didn't express well my question.
> For the autofill case (type/paste something and Enter) it's clear that we
> want separate entries. That's what I'll do here.
> 
> I'm instead asking if we should change the action string for the _other_
> entries in the popup, the ones the user has to select explicitly, where we
> won't have a dupe entry, but only the switch to tab one.

Thanks for clarifying! At this point I think we can leave the strings as they are.  I'm worried having too much copy will decrease the scan-ability of the list.  We can keep this as a power user function for now.

Comment 27

[Drew Willcoxon :adw]

Comment on attachment 8957586 [details]
Bug 1439728 - Don't force a switch-to-tab for the Address Bar heuristic match.

https://reviewboard.mozilla.org/r/226478/#review232860

Looks good, works well.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7a80eecd0470
Don't force a switch-to-tab for the Address Bar heuristic match. r=adw

Comment 29

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/7a80eecd0470

Comment 30

[Marco Bonardo [:mak]]

Comment on attachment 8957586 [details]
Bug 1439728 - Don't force a switch-to-tab for the Address Bar heuristic match.

Approval Request Comment
[Feature/Bug causing the regression]: bug 1433938
[User impact if declined]: We introduced a behavioral change where autofill can switch to tab, users find that confusing and UX wants us to revert that change
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: not yet
[Needs manual test from QE? If yes, steps to reproduce]: not necessary
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not particularly
[Why is the change risky/not risky?]: reverting behavior, small patch
[String changes made/needed]: none

Comment 31

[Julien Cristau [:jcristau]]

Comment on attachment 8957586 [details]
Bug 1439728 - Don't force a switch-to-tab for the Address Bar heuristic match.

awesomebar regression fix, beta60+

Comment 32

[Dorel Luca [:dluca]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d30ae32ee90e

Comment 33

[Andrei Vaida [:avaida]]

Setting qe-verify- on this bug since it has automated coverage and Marco considers manual testing unnecessary (Comment 30).