Last Comment Bug 546254 - Give open-page autocomplete tab matches a higher frecency ranking (weight, priority)
: Give open-page autocomplete tab matches a higher frecency ranking (weight, pr...
Status: NEW
[switch-to-tab]
:
Product: Toolkit
Classification: Components
Component: Places (show other bugs)
: Trunk
: All All
: -- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Marco Bonardo [::mak]
Mentors:
: 577239 578336 769223 (view as bug list)
Depends on: 546253
Blocks: switch-to-tab
  Show dependency treegraph
 
Reported: 2010-02-14 23:57 PST by Blair McBride [:Unfocused] (UNAVAILABLE)
Modified: 2015-03-17 06:37 PDT (History)
22 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments

Description Blair McBride [:Unfocused] (UNAVAILABLE) 2010-02-14 23:57:08 PST
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) 2010-06-29 09:10:50 PDT
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) 2010-06-29 10:55:42 PDT
Requesting blocking final. This puts the feature in front of the user sometimes, and hides it away other times. Very frustrating.
Comment 3 Marco Bonardo [::mak] 2010-07-07 11:11:11 PDT
*** Bug 577239 has been marked as a duplicate of this bug. ***
Comment 4 Jo Hermans 2010-07-13 05:53:44 PDT
*** Bug 578336 has been marked as a duplicate of this bug. ***
Comment 5 Benjamin Smedberg [:bsmedberg] 2010-07-20 13:16:54 PDT
I think we want frecency changes to end up in a beta sooner rather than later.
Comment 6 Shawn Wilsher :sdwilsh 2010-07-21 07:26:41 PDT
After talking with beltzner/johnath on irc, we think Blair might be better suited to fix this bug.
Comment 7 Marco Bonardo [::mak] 2010-09-03 03:17:32 PDT
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 2010-09-03 03:37:38 PDT
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] 2010-10-01 13:45:00 PDT
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] 2010-10-01 13:49:34 PDT
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) 2010-10-01 14:13:13 PDT
>'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] 2010-10-01 14:21:01 PDT
(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] 2010-10-01 14:27:06 PDT
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) 2010-10-05 16:15:09 PDT
(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 2011-02-05 06:16:40 PST
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 16 Dão Gottwald [:dao] 2012-07-02 14:04:20 PDT
*** Bug 769223 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.