546254 - Give open-page autocomplete tab matches a higher frecency ranking (weight, priority)

Status: NEW

(Toolkit :: Places, defect, P3)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Followup to bug 480350.

Open-page matches are currently ranked no different from a page that isn't currently open. Need to experiment with ranking them higher, since they could be of higher relevance.

Comment 1

[Dietrich Ayala (:dietrich)]

This is hurty once you've become used to switch-to-tab.

The scenario that happens to me 20x daily is that I need to switch back to gmail, but I have a message open there, so the tab result doesn't show up in the visible result set - it's crowded down by all the other gmail results, like the inbox and filters i view often.

Comment 2

[Dietrich Ayala (:dietrich)]

Requesting blocking final. This puts the feature in front of the user sometimes, and hides it away other times. Very frustrating.

Comment 5

[Benjamin Smedberg]

I think we want frecency changes to end up in a beta sooner rather than later.

Comment 6

[Shawn Wilsher :sdwilsh]

After talking with beltzner/johnath on irc, we think Blair might be better suited to fix this bug.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

is the situation still so bad? After landing of bug 546253 we run the switch-to-tab query before any other query, and many results should have been bumped up.

Comment 8

[Reece H. Dunn]

My subjective opinion is that the situation has improved w.r.t. showing open tabs.

Doing a test with Google Mail, Calendar, Docs, Reader, Web Search (x2) open and a handful of others, typing 'g' shows about 2 tabs in the results, while 'go' is filled with the Google tabs in the first 6 results. This indicates that if you have 10-20 tabs open, they are likely to dominate the top 6 results in the awesome bar, so appears (from this simple test) that the results have swung the other way.

Ideally, there should be a 50-50 split in the top 6 results (e.g. by interleaving 'search', 'tab', 'search', 'tab', ..., with the remaining results set to 'search' if there are no other matching tabs). This approach should keep the results balanced irrespective of any tuning changes.

Comment 9

[Johnathan Nightingale [:johnath]]

Based mostly on comment 7, I don't believe the remaining work blocks FF4, but feel free to re-nom if I'm reading too much into that.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Dunno - as this screenshot shows, they're still not always the first things in the drop-down:

http://grab.by/6EUC (yes, I viewed 595455 a lot, but not in the past few weeks; feels like that should be below the tabs that I've got currently open)

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>'re still not always the first things in
>the drop-down

making them arbitrarily first will break the adaptive learning of the awesome bar.  The goal is to remove duplicate tabs, so I believe these should be just as easy to access as it would be to do a new navigation to the same site.  Otherwise one's existing tabs (especially if the use has a lot of them) are going to get in the way of fresh navigations.

Comment 12

[Rob Arnold [:robarnold]]

(In reply to comment #11)
> >'re still not always the first things in
> >the drop-down
> 
> making them arbitrarily first will break the adaptive learning of the awesome
> bar.  The goal is to remove duplicate tabs, so I believe these should be just
> as easy to access as it would be to do a new navigation to the same site. 
> Otherwise one's existing tabs (especially if the use has a lot of them) are
> going to get in the way of fresh navigations.

This is currently the case for me - I have an open tab that is always the first instead of the much more frequent fresh navigation that I want.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

You misunderstand. In the case I illustrated, I hadn't been to the top result in weeks, at which point I do not think that it should be above the open tab entries.

We need to tweak the frecency bonus for open tabs so that it's appropriate. I think it's a different algorithm than we normally used, much more heavily based on:

 - how recently the tab was opened
 - how frequently the user switches to the tab using the awesomebar
 - how recently the other navigation entries were used

Comment 14

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #13)
> We need to tweak the frecency bonus for open tabs

To clarify: tab-matches currently have *no* frecency bonus. They actually can't, yet - that ability needs to be added (so its not just a matter of changing the value of some variable/pref somewhere).

Comment 15

[avada]

I'm against this. 
I found this feature lot more often annoying than useful. Especially because 555694. But if it starts contaminating my expected results with tabs that I have open then it will be utterly frustrating. Having to scroll down a lot to find what I want or type a lot more.
I only found it useful in one occasion. When I forgot about one tab and I tried to open it again I saw it was already open. But even this wouldn't work as well if tabs get higher frecency.

Why another way to switch tabs? You can click with mouse, there is ctr+tab, there's panorama. This one just impairs the functionality of the location bar. And its more cumbersome than the others. A tab candy quick search shortcut would be more useful. That way you wouldn't mix tabs with history.

Comment 19

[Dietrich Ayala (:dietrich)]

The problem remains for me - comment #1 still stands true after its 10 year anniversary 🥳

I think the problem got marginally better after the score tweaks ~9 years ago.

But now I see very mixed results:

• Sometimes the tab I'm searching for is in results 3-5

• Sometimes I cannot get it to show up no matter what I type into the awesomebar

• It's basically never the top result, which is quite odd now that I think of it

I would like to test the assertion in comment #11 and try living with open-tabs-forced-on-top for bit.

Marco, which pref can I tweak to make that happen? It's been a long time since I looked through that code 😅

Comment 20

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

For now the simplest workaround is to type the % char at the beginning or end of your search terms. That limits results to open tabs. We have some plan to make those more discoverable, but still in the design phase. Afaik at the moment there's no pref you can tweak to bump up open tab results.

Comment 22

[Robb Eesh]

For now the simplest workaround is to type the % char at the beginning or end of your search terms. That limits results to open tabs.
This is ok if you're already aware of the fact that the tab is open.

My typical scenario is that I want to go to a page, and I'm not sure whether I have a tab open to that page or not. I'd like Firefox to suggest the existing tab first, so I can avoid opening a new tab to the same page.

For example : my calendar is currently open in a tab, but the URL of the page changes every week. If I start writing "calendar" in my search bar, the existing open tab will not be suggested.

With the % method, I have to manually check whether or not an existing tab is open, and then open a new one. If the opened tab was prioritized, the very action of writing the search query would inform me of the fact that the existing tab exists, promoting better tab hygiene in the process.

Comment 24

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

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 25

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 26

[Shane Rodriguez]

Attachment: same problem

Thanks from loophebalvi1987.