Typing % in the url bar does not search synced tabs
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox78 | --- | verified |
People
(Reporter: clessili, Assigned: bugzilla)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0
Steps to reproduce:
Type '%' followed by the title of a synced tab.
Actual results:
No synced tabs appear.
Expected results:
Typing keywords without '%' suggests synced tabs and open tabs.
With '%', the dropdown should list synced tabs along with open tabs.
![]() |
||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Is this a regression (used to work, now it's broken), or an enhancement request?
Enhancement request, I don't think it ever worked.
Comment 3•4 years ago
|
||
Comment 4•4 years ago
•
|
||
The first problem is how we match, we pass the original search string "%" to getMatches, and then match on it, rather than just returning all the entries:
https://searchfox.org/mozilla-central/rev/b38e3beb658b80e1ed03e0fdf64d225bd4a40327/toolkit/components/places/PlacesRemoteTabsAutocompleteProvider.jsm#144
There is also the question of how to handle clash with local tabs, maybe only return a max of (maxRichResults/2) remote tabs? Because they will push away local tabs completely (if you have 10 remote tabs). Like in other cases we should add a few results, put the others aside, and if we don't find local tabs, add back the reserved ones.
Finally, Remote tabs are returned only if they were visited on mobile in the last 72 hours, for example in my case PlacesRemoteTabsAutocompleteProvider.getMatches("%") returns one entry, but it's older than 72 hours, thus I don't see it.
So, I think the only problem is handling the special restriction char in getMatches, and putting a limit.
Updated•4 years ago
|
Note that in my duped-here bug 1575558, I have only two Firefox Desktop instances linked to my FxA, and so
Remote tabs are returned only if they were visited on mobile in the last 72 hours
it may be that "on mobile" is instead "on another Firefox instance"?
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
Engineering discussed this with Verdi. There are some difficulties with this bug because we don't have a way to sort open tab and remote tab results together, since Desktop and mobile use different frecency scales. Short of that, we're just going to show up to 5 remote tab results and maxRichResults - numberOfRemoteResults
open tab results, with all of the remote tab results appearing after the open tab results. We can tweak this behaviour once we have an initial implementation.
Comment 8•3 years ago
|
||
I think currently remote tabs appear above other results (TBV)
Assignee | ||
Comment 9•3 years ago
|
||
Also, it probably makes more sense to show maximum maxRichResults / 2
remote tab results rather than 5, to accommodate edge cases where people have changed maxRichResults
.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 10•3 years ago
|
||
Assignee | ||
Comment 11•3 years ago
|
||
Like Marco said in comment 4, the issue here is that we pass the "%" character to PlacesRemoteTabsAutocompleteProvider.getMatches
. We should pass the search tokens instead.
Comment 12•3 years ago
|
||
Pushed by htwyford@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/60a406d3b53a Return remote tab results for searches for '%'. r=adw
Comment 13•3 years ago
|
||
bugherder |
Comment 14•3 years ago
|
||
I reproduced this issue using 70.0a1 (2019-07-31) on Windows 10 x64.
I can confirm the fix, I verified using Fx 78.0 on Windows 10 x64 and macOS 10.13.
Description
•