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.
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.
Requesting blocking final. This puts the feature in front of the user sometimes, and hides it away other times. Very frustrating.
*** Bug 577239 has been marked as a duplicate of this bug. ***
*** Bug 578336 has been marked as a duplicate of this bug. ***
I think we want frecency changes to end up in a beta sooner rather than later.
After talking with beltzner/johnath on irc, we think Blair might be better suited to fix this bug.
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.
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.
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.
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)
>'re still not always the first things in
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.
(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.
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
(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).
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.
*** Bug 769223 has been marked as a duplicate of this bug. ***