1760344 - Address bar search tabs feature doesn't return open tabs

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect, P3)

Description

[Asif Youssuff]

This bug is annoying because it seems like address bar search results are non-deterministic, so mozregression runs return strange results. Happy to try to enable logging as necessary to get to the bottom of this.

Steps to reproduce:

1. Open many tabs
2. Open chat.mozilla.org (Element) in a tab
3. Switch to another tab and do Ctrl-l
4. type "% element"

What happens:

Get results for Element as a tab on a remote device or the string "element" in URL.

Expected result:

The "Element" tab is surfaced as the first result as prior to regression.

42:26.66 INFO: Narrowed integration regression window from [76c68029, 6630c5fd] (3 builds) to [76c68029, 844b96d8] (2 builds) (~1 steps left)
42:26.66 INFO: No more integration revisions, bisection finished.
42:26.66 INFO: Last good revision: 76c68029dfca33c918cdb9abb6c66d4876aafcda
42:26.66 INFO: First bad revision: 844b96d8f690c6f0d997c1bed10c9a66c9d2ef85
42:26.66 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=76c68029dfca33c918cdb9abb6c66d4876aafcda&tochange=844b96d8f690c6f0d997c1bed10c9a66c9d2ef85

This regression range may be wrong! Address bar results are non-deterministic, and I occasionally saw Element in search results - but I marked the build bad if I didn't see it after a few tries.

Comment 1

[Asif Youssuff]

Attachment: about:support

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1744069

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:miko, since you are the author of the regressor, bug 1744069, could you take a look?
For more information, please visit auto_nag documentation.

Comment 4

[Asif Youssuff]

Attachment: element-good.png

Comment 5

[Asif Youssuff]

Attachment: element-bad.png

Comment 6

[Miko Mynttinen]

It is highly unlikely that the changes in bug 1744069 would cause this. In both screenshots the search suggestions seem to render as they should so it does not look like a graphics problem.

Am I understanding the problem correctly: your local open tabs are missing from the search results?

Comment 7

[Asif Youssuff]

Am I understanding the problem correctly: your local open tabs are missing from the search results?

Yes, exactly.

Yeah - I wasn't confident that the regression range was correct. :(

Comment 8

[Dianna Smith [:diannaS]]

Is there a way to get a another regression range for this as well as priority/severity?

Comment 9

[Drew Willcoxon :adw]

Asif, do your open tabs happen to be in a different container? Other than that, these recent-ish bugs might have changed the behavior:

• Bug 1720369 - Switch to Tab option appears in Private window for non-Private Tab Using Search Shortcut
• Bug 1677126 - Split UrlbarProviderRemoteTabs from UnifiedComplete
• Bug 1662167 - Split UrlbarInputHistoryProvider from UnifiedComplete

The last two especially created new providers that can return remote tab and switch-to-tab results independently. The remote tab provider might be "winning" for you and returning results before other providers can return switch-to-tab results. But even so, the result groups should take care of that by limiting the number of remote tab results.

Can those three bugs help you narrow down a valid regression range? That would be a big help.

Comment 10

[Asif Youssuff]

Attachment: ranking

Asif, do your open tabs happen to be in a different container?

They aren't, I have known about that for a loooong time. ;)

In any case, I'm not seeing the issue anymore - or at the very least, I am able to locate the Element tab that I have opened without too much fuss.

I still think it is weird that remote tabs would "win" a higher rank than local tabs - although the help states "Add % to show only matches in your currently open tabs." and I suppose technically, they are "open" somewhere, I would strongly prefer to see local results first, because in the remote tab case, I am not opening that tab at all, I am opening a page that corresponds to a tab on a different device.

It may still be valuable to get that page, but ranking it above tabs I can switch to via the awesomebar feels like an odd choice to me.

Are you aware of whether this is designed behavior? Either way, I'm guessing that this bug can be closed, especially since the regression range seems not particularly valuable.

Comment 11

[Drew Willcoxon :adw]

Yes, remote tabs are generally ranked above local tabs. The related code for that is here, where the result groups are created. The REMOTE_TAB and GENERAL groups have a ratio of 1:2, with remote tabs first, so in a list of 10 results, we would expect 3 remote tabs followed by 7 local tabs, assuming there are plenty of each, which is what your screenshot shows. There's a little bit of complexity with the INPUT_HISTORY groups because local tabs can be included in them too, so you may sometimes see local tabs above remote tabs.

I'm not sure why we chose to show remote tabs first though. Feel free to file an enhancement bug for allowing the user to modify that behavior.

I'll go ahead and close this, but please let us know if it happens again. If you do actually have open tabs that match your search but all you're seeing is remote tabs, that does sound like a real bug, although it may be hard to diagnose and fix due to the timing issue as I mentioned earlier.