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.

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.

(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?

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?

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?

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.

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.

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?

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?

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.

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

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.

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.

Yeap, this bug is still relevant.

(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?

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!

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.

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?

Oiriginal patch author: Paresh Malalur <atararx@gmail.com>