1479858 - % prefix search only finds switch to tab entries for the current container

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Steve Fink [:sfink] [:s:]]

I frequently use the % prefix in the address bar to find open tabs, and for a while now (a month or two?), it has been failing to find things that it used to be able to find.

Current example: I have the url https://reviewboard.mozilla.org/r/259408/diff/1#index_header open, with title "Bug 1478393 - Add AutoGeckoProfilerEntry to js parsing in BytecodeCompiler::compileScript r?mstange | Diff Viewer | Review Board".

When I entered "% 1478" into the address bar, it shows my (pinned) gmail tab with a message related to that bug, but it did not find the above open tab. Once I found the tab by linearly searching through my 301 open tabs and switched to it and then back away, the same search switched to only showing the (desired) reviewboard tab and *stopped* showing the gmail tab. (The gmail tab's URL does not contain the bug number, but its title does; same as the reviewboard page.)

Note that the tab *was* loaded already when I first searched; it was opened only shortly before in the same browser session.

This has been bothering me for a while, but I think what stopped me from filing a bug earlier is the changing behavior -- whenever I tried to write up an exact description of what was happening, it magically started to "work".

Comment 1

[Steve Fink [:sfink] [:s:]]

Oh! It appears that it is searching only in the current container. I do not want that. I very much want it to search all containers. It would be great if the dropdown had the color indicator of which container each search result was found in, but I really do not want it to omit the other containers' tabs.

Comment 2

[Steve Fink [:sfink] [:s:]]

I have Firefox Multi-Account Containers installed, if it matters.

Comment 3

[Asif Youssuff]

Given that Bug 1516083 just got resolved and added as a feature, it feels weird that the current behavior where searching across containers isn't the default.

Prior, it was a less discoverable feature, but given that it is now a first class feature in the GUI, I hope this ticket can be resolved.

Comment 4

[Dão Gottwald [:dao]]

Marco, what do you think?

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This was implemented in bug 1287866, the reasoning is pretty much in the first 2 comments there.
I think in general what was implemented there makes sense, the user may want the same page in different containers, and may not want to switch.

Though, the "%" case is a bit special, in this case the user is explicitly saying he wants to switch, and in this case it would make sense to provide all the switch tab entries, regardless of their container.

This would probably satisfy both the original concern, and the use-case pointed out here.

It shouldn't be too complex to do, we should basically check if there's a tab switch restriction token and modify the SQL queries to skip the t.userContextId filter in such a case.

Comment 7

[Dão Gottwald [:dao]]

Given how the UI exposes this (bug 1516083), suggesting that this would search across all tabs, I'd say this is actually a defect at this point.

Comment 9

[:Gijs (he/him)]

Combined with container add-ons that automatically open some sites in a specific container, and otherwise using accel-t to open tabs, this is a little cumbersome - the new tab is always in the default container, but typing in the URL bar then never ends up suggesting open tabs for the sites that are forced to open in the same container anyway.

Comment 10

[Dão Gottwald [:dao]]

(In reply to :Gijs (he/him) from comment #9)

Combined with container add-ons that automatically open some sites in a specific container, and otherwise using accel-t to open tabs, this is a little cumbersome - the new tab is always in the default container, but typing in the URL bar then never ends up suggesting open tabs for the sites that are forced to open in the same container anyway.

This suggests that we should revert bug 1287866 rather than fixing only % as suggested in comment 5. mak?

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

There's nothing for which the points from bug 1287866 suddenly became invalid, thus I'm not sure why we should revert it, that'd reintroduce the original bug.
The problem is that we have 2 group of users that would like the feature to work in opposite ways:

1. someone prefers switch to tab to never escape the current container
2. someone prefers switch to tab to just be global
   I don't think we can make a call about who is right, that seems to call for a user facing option.

The % restriction char, if fixed as suggested in comment 5, would be a simple way of escaping the default behavior, by ignoring the current container. If we'd have the search button with an option to search open tabs in the current container or globally, it would also be a nice visual escape (but at this point I doubt it'll ever exist).
Surely we can investigate more changes, when they make sense. The case from comment 9 (empty new tab) is interesting and may be another case where we would like to ignore the current container. Maybe by fixing the most common cases and by providing an escape path (#) we could avoid the option toggle?

Comment 12

[Teal Bauer [:teal]]

This behavior has bit me a few times as well and I would love to see it resolved in some way.

I don’t know enough about the internals of MAC to judge how hard it would be to do, but an option to deal with the potential ambiguity of having the same URL open in multiple containers, annotating the result list with the appropriate container seems like a workable compromise (i.e. “Switch to tab in [Work] container”, ideally with coloring).

The order of open-new/match-in-container/match-global could be something that is exposed as a hidden preference, or something the AwesomeBar learns with time, i.e. whether there is usually only one match (global use) or multiple across containers.

My gut feel is that most people would use the switch behavior with reference-style pages, i.e. there would only be one instance; an exception could be users that navigate almost entirely by keyboard who would use the typeahead or %-tag where other users would use tab-switching hotkeys or pointer devices?

Comment 13

[Benyamin Limanto]

Wow. It's really 3 years ago. I wonder why it still need sometimes to fix it. I agree with Matthias, the option should be provided to the end user so they could choose themselves. I do % for some tabs, and this way way of FF works for now really bothers me. Thank you.

Comment 14

[Timvde]

Surely we can investigate more changes, when they make sense. The case from comment 9 (empty new tab) is interesting and may be another case where we would like to ignore the current container. Maybe by fixing the most common cases and by providing an escape path (#) we could avoid the option toggle?

I feel like a simpler solution exists: the original bug was clearly about "escaping a container", where the user explicitly opened a container tab and then got redirected to the open tab in the default container. It is indeed clear to me that that probably shouldn't happen (and making an exception for new tabs wouldn't solve this issue), but the differentiating point there is (imo) being in a container vs not being in a container (the default one).

Firefox could suggest switching to any tab in any container when the user isn't specifically operating in a containerized tab, and only show tabs from the current container when they are. As a side note, it would also be massively useful to indicate which container a suggested tab in the location bar is in.

Edit: Somebody pointed out to me that it wasn't clear that I am only talking about the awesome bar deciding for itself to suggest to switch tabs. If the user explicitly types a %, I believe all tabs should be shown, regardless of the current container.

Comment 16

[Hemant Kumar]

Those of us who use containers and have more than 10-15 tabs open, the default behaviour of '%' restricting to current container makes little sense. Adding a preference/config option will work for me, so as I can at least change the default behaviour.

This bug has been open for awhile. Are we accepting contributions for this?

Comment 17

[jimaldon]

The default and un-configurable behaviour of searching only within the current container group makes it hard for immediate tab switching. Is fixing this a priority?

Comment 18

[Hemant Kumar]

I hate to pile on this, but this is a important bug that hugely affects usability of containers and IMO should be fixed. I personally would prefer that '%' worked across containers but reading the history, I don't mind if there is an option to enable this either in containers add-on itself or in firefox somewhere.

Comment 19

[jscher2000]

FYI, raised on SUMO again today: https://support.mozilla.org/questions/1369396

Comment 20

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

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 40 votes.
:adw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 21

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 22

[Robson Sobral]

Yeap, this bug is still relevant.

Comment 23

[oshbug]

(In reply to Hemant Kumar from comment #18)

I hate to pile on this, but this is a important bug that hugely affects usability of containers and IMO should be fixed. I personally would prefer that '%' worked across containers but reading the history, I don't mind if there is an option to enable this either in containers add-on itself or in firefox somewhere.

Fully agree with this. Why is this marked as such a low priority?

Comment 24

[Chris Bellini (:cbellini)]

It's great to see interest in this bug. Improving the experience of searching across containers is something we're planning to improve next year - stay tuned!

Comment 25

[atararx]

Attachment: Bug 1479858 - Added option for UrlBar search open tabs to ignore userContextId. r?[e-mail]

User context can now be ignored during searching open tabs (using '%')
via the about:config flag
browser.urlbar.searchOpenTabs.searchAllContainers. It is set to
false by default to replicate the current behavior. But when it is
set to true, all open tabs are searched.

Comment 26

[Marc Seibert (:mseibert)]

Hey atararx, I saw there are few remaining things to address in the current revision. Can I help you in any shape or form to push this patch towards completion?

Comment 27

[Marc Seibert (:mseibert)]

Attachment: Bug 1479858 - Added option for UrlBar search open tabs to ignore userContextId.r=mak

Oiriginal patch author: Paresh Malalur <[e-mail]>

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a299a80db1af
Added option for UrlBar search open tabs to ignore userContextId.r=mak,dao

Comment 29

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/a299a80db1af

Comment 30

[Ardelean Oana, Desktop QA [:oardelean]]

Reproducible on a 2023-10-10 Nightly build on Windows 10.
Verified as fixed on Firefox 120.0 and Nightly 121.0a1 on Windows 10, Ubuntu 22, macOS 12.