1945063 - Tabs filter causes address bar not to produce switch-to-tab results that it does produce when not filtering tabs

Status: NEW

(Toolkit :: Places, defect, P3)

Description

[:Gijs (back Mon 10; he/him)]

My daily driver profile on Windows has this strange issue and I'm finally finding time to report it...

I have about 12 windows open. One of them has a pinned tab to, let's say https://foo.example.com. I have no other tabs with that toplevel domain. I also have sync and have another desktop session and a mobile one. None of them have tabs with this domain. If it matters, the tab title/label is also "Example" (but different capitalization).

If I go to the address bar in another window, type "example", then I get an autocomplete result with a "switch to tab" chiclet for the aforementioned pinned tab (top result). I also see 5 history results from different domains that happen to contain this string, and 3 default search engine suggestions.

If I go to the address bar and type "% example", then I do not get any results. This does not make any sense to me. Clearly some part of my browser knows the tab exists, and some other part refuses to believe it. :-)

Happy to open a browser debugger or do logging or something, but not sure where to start to debug this.

Comment 1

[:Gijs (back Mon 10; he/him)]

Marco helped me debug this (thank you!) and it seems this would likely be resolved by the fix in bug 1939597. For some reason, the frecency column for this site in moz_places is 0, and the last visited date is almost 2 months ago - even though the tab is pinned and as this is a Windows desktop machine, it gets shut down at night and boots fresh every morning, and so does Firefox (with automatic session restore turned on), and I would have expected that to "count"... I also don't recall seeing an error on this page recently, but of course it's possible I'm misremembering.

I'll verify early next week when this profile will update to 137 beta.

Comment 2

[Marco Bonardo [:mak]]

I'm moving this to Places, as I think the only relevant remaining thing here is the site being at zero frecency.
I think it's related to session restore keeping the page open in the pinned tabs, and then Global History doesn't record new entries and frecency suffers.
James is working on a frecency improvement that will help with this case, in Bug 704027.
Apart from that, we could evaluate adding "virtual" visits in these restore cases, I think they would not be completely unxepected from the user side.

Comment 3

[Mark Banner (:standard8)]

We think the current changes will solve most of the user facing issues, and what is left is figuring out how to handle the frecency zero case related to session restore.

Comment 4

[:Gijs (back Mon 10; he/him)]

FWIW the practical problem went away for me with 136 beta - the 0-frecency item now shows up in tab switch - but indeed having the frecency not be 0 seems sensible. :-)