Give open-page autocomplete tab matches a higher frecency ranking (weight, priority)
Categories
(Toolkit :: Places, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: Unfocused, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [switch-to-tab])
Updated•15 years ago
|
Updated•15 years ago
|
Updated•15 years ago
|
Updated•14 years ago
|
Comment 1•14 years ago
|
||
Reporter | ||
Updated•14 years ago
|
Comment 2•14 years ago
|
||
Comment 5•14 years ago
|
||
Comment 6•14 years ago
|
||
Comment 7•14 years ago
|
||
Comment 8•14 years ago
|
||
Comment 9•14 years ago
|
||
Comment 10•14 years ago
|
||
Comment 11•14 years ago
|
||
Comment 12•14 years ago
|
||
Comment 13•14 years ago
|
||
Reporter | ||
Comment 14•14 years ago
|
||
Comment 15•14 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Updated•8 years ago
|
Comment 19•5 years ago
|
||
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•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 22•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Comment 24•2 years ago
|
||
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•2 years ago
|
||
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.
Description
•