Hidden tabs are listed in "Recent tabs"
Categories
(Firefox :: Session Restore, defect)
Tracking
()
People
(Reporter: mystiquewolf, Assigned: mystiquewolf)
References
Details
Attachments
(2 files, 1 obsolete file)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
- Install Tab Stash extension
- Have about 7-8 opened tabs
- Stash one of the tabs
- Press and hold
Ctrl
key and clickTab
key while still holdingCtrl
key and without releasingCtrl
key
Actual results:
The just hidden/stashed tab is shown in the "Recent Tabs" list. On selection it is activated/unstashed/shown, while in the extension it still shows as stashed. Now your options are to either:
- Close the tab, so that it doesn't show in the "Recent Tabs" list anymore, but at the price of losing the tab state (filled forms, scrolled position, etc..)
- Open the "Tab Stash" extension's own list of tabs, delete the stashed tab from its collection, stash it again, which leaves us again at starting position - tab is again hidden and stashed, but you have the same problem - tab appears in "Recent Tabs". Now you always have to be careful not to select/activate it and you can't just afford to use Ctrl + Tab fast without showing and looking detailed at the list of tabs to see whether one of the tabs is supposed to be stashed/hidden. Now imagine this situation with 300 tabs, 290 of which were recently stashed for example. "Recent Tabs" list would be populated with stashed tabs and you could not use the "Recent Tabs" list anymore due to this. Even with just 15-20 Recently stashed tabs the situation is the same so it's not that only people with lots of tabs would experience this.
Expected results:
Hidden tabs should not show in the "Recent Tabs" list that is opened via Ctrl
+ Tab
, they were just right now hidden and there is no use case IMO that would require instant switching back to them and thus activating them. Moreover they can be seen via the "All Tabs" list from the dropdown near the new tab button - there is a hidden tabs list inside this list and also there is an introduction to this feature so people already know which extension hid the tabs and where the hidden tabs can be found.
Assignee | ||
Comment 1•3 years ago
|
||
What i suggest to do is to only hide the tabs cosmetically, that is, keep the "Recent Tabs" order for hidden in the backend, just skip such tabs on painting. That way if these tabs are later unhidden all at the same time, the order would still be correct.
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•3 years ago
|
||
Moving over to WebExtensions, please revert in case that's not correct. However, to add improvements you should contact add-ons' developer.
Assignee | ||
Comment 4•3 years ago
|
||
The "Recent Tabs" list is provided/displayed by Firefox so it can only be fixed there, but let's see if WebExtensions people have something to offer - maybe an API for extensions to select whether the just hidden tab should be hidden or not from the "Recent Tabs" list.
Comment 5•3 years ago
|
||
Hello, I am the developer of Tab Stash. I agree with the OP that this is an issue with Firefox's handling of hidden tabs, not an extension issue per se. I imagine all extensions which use the WebExtension hidden-tabs API will face this issue, but WebExtension folks please let me know if I'm mistaken. Thanks!
Comment 6•3 years ago
|
||
Hello,
I reproduced the issue on the latest Nightly (94.0a1/20210919212908), Beta (93.0b7/20210919190049) and Release (92.0/20210903235534) under Windows 10 x64 and Ubuntu 16.04 LTS.
After enabling the “Ctrl+Tab cycles through tabs in recently used order” feature from about:preferences I went ahead with the reproduction steps and indeed, the hidden/stashed tab is shown in the “Recent Tabs” list although the extension lists it as still stahsed.
For further details, please see the attached video.
The WebExtensions dev team will take a look and confirm/disprove if this is indeed related to any webextesnions API or an issue with Firefox itself.
Comment 7•3 years ago
|
||
Comment 8•3 years ago
|
||
Only extensions can hide tabs, but the actual implementation is in non-extension code.
Implementation entry point is at https://searchfox.org/mozilla-central/rev/13378066961f195595822d4f543c8ac5b7f46490/browser/components/customizableui/CustomizableWidgets.jsm#203
RecentlyClosedTabsAndWindowsMenuUtils.getTabsFragment
is implemented at https://searchfox.org/mozilla-central/rev/13378066961f195595822d4f543c8ac5b7f46490/browser/components/sessionstore/RecentlyClosedTabsAndWindowsMenuUtils.jsm#25-71
To resolve this bug, the latter function could be updated to exclude hidden tabs.
@:mystiquewolf: If you're interested in contributing a patch, see https://firefox-source-docs.mozilla.org/contributing/index.html to get started.
Comment 9•3 years ago
|
||
The severity field is not set for this bug.
:dao, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 10•3 years ago
|
||
Been interesting for a long time to contribute to Firefox so might do it but not sure if or when as my plate is usually full with things to do, so if someone else comes here and wants to do it feel free to do it.
Assignee | ||
Comment 11•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 12•3 years ago
|
||
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Comment 14•3 years ago
|
||
Backed out for causing failures at browser_datachoices_notification.js.
Backout link: https://hg.mozilla.org/integration/autoland/rev/c17b2ed4fe610dd66e65ed8e01e360073833bb83
Failure log: https://treeherder.mozilla.org/logviewer?job_id=363118771&repo=autoland&lineNumber=6209
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 15•3 years ago
|
||
@dao I've updated the revision, could you please reland?
Comment 16•3 years ago
|
||
Comment 17•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 18•3 years ago
|
||
It seems that we were enjoying this behavior without noticing that it was considered a bug. Some FF extensions are broken now. They deal with multiple open tabs use hiding to show only une group of tabs at a time, but we need to be able to go back to the last used tab (with Ctrl+Tab) even though it belongs to another group (i.e. it is hidden now).
My suggestion is: why don't make it configurable? I mean, leave this fix by default but allow some users to use Ctrl+Tab even with hidden tabs.
See a relevant discussion here:
https://www.reddit.com/r/firefox/comments/tb151s/unable_to_switch_to_hidden_tabs_using_ctrltab/
Thank you for your time.
Sincerely,
Daniel.
Assignee | ||
Comment 19•3 years ago
|
||
Daniel, could you please write detailed steps to reproduce (see Comment #0) exactly how the extensions are broken?
For example:
- Install extension X
- Open 4 tabs
- Click A
- Click B
- Press Ctrl + Z keys
Also, include specific settings for the extensions if they matter.
Comment 20•3 years ago
|
||
If you believe that there is broken behavior, please file a new bug with reproduction steps, and reference this bug for visibility.
This bug is already closed / resolved. You shouldn't report bugs in closed bugs because there is a high chance that the report gets lost.
Assignee | ||
Updated•3 years ago
|
Comment 21•3 years ago
|
||
I understand that this was a bug, but it also breaks the behavior of users of extensions such as
- https://addons.mozilla.org/en-US/firefox/addon/simple-tab-groups/
- https://addons.mozilla.org/en-US/firefox/addon/panorama-tab-groups/
When you switch from a group to another because of an URL matching, for example, all your tabs gets hidden.
If you hit Ctrl+Tab to go back to the previously used Tab, you're now going to the previous tab in the new group.
Now, I think the normal behavior is completely fine for users who explicitly hide a tab, but it would be good to have an about:config
flag or something extensions can tune, to preserve previous behavior in specific cases.
Description
•