Open Bug 1765900 Opened 2 years ago Updated 2 years ago

Add pref to hide/show hidden tabs in Ctrl+Tab panel (& expose it through WebExtensions browserSettings API?)

Categories

(Firefox :: Session Restore, enhancement)

Product:
Firefox
Component:
Session Restore
Platform:
Desktop
Unspecified
Type:
enhancement

Tracking

()

Tracking Flags:
Tracking Status
firefox101 --- affected

People

(Reporter: aminomancer, Unassigned)

References

Details

As of bug 1731050, hidden tabs are elided from the "Recent tabs" panel (Ctrl+Tab). Apparently this can interfere with how users habitually use extensions that create tab groups by hiding tabs.

There are some suggestions in the comments that a preference would resolve this, but since tabs can only be hidden by extensions (currently, and for the foreseeable future), this seems like a good use case for the browserSettings API. I'm sure there are many more users of the extensions in question than there are users who will hear about an obscure new pref they can toggle manually.

I guess another possibility would be to add a property to the tab object that says whether it should be hidden from all tab views or just the tab strip and "all tabs" menu, and then allow extensions to set this. But that seems really convoluted, and I'm struggling to imagine a use case where a single extension wants to hide some tabs from ctrlTab panel but not other tabs.

Thanks Shane for filing this up. The browserSettings API is the about:config page?

(In reply to Daniel Sottile from comment #1)

Thanks Shane for filing this up. The browserSettings API is the about:config page?

No, that's an API that allows extensions with the permission to read and/or write a specific set of preferences relevant to extensions. So if a new pref was added, a browserSettings implementation could allow extensions to set it without the user needing to know about the new pref.

I think this should at most be a per-extension setting, not a global setting in any way.
If the setting was being set through the browserSettings API, extensions would conflict in their needs. You might have two extensions and want the tabs hidden by one of them to not show in recent tabs until unhidden / unstashed (say, Tab Stash extension), and tabs hidden by the other extension to be switchable (say, Simple tab groups).

So probably a per-tab setting in addition to the hidden setting. Also, probably move this bug to the WebExtensions component for some feedback?

(In reply to Lyubomir [:mystiquewolf] from comment #3)

I think this should at most be a per-extension setting, not a global setting in any way.

I'm not sure I understand how a per-extension setting would work. Extensions are installed simultaneously and are managing the same set of tabs.

If the setting was being set through the browserSettings API, extensions would conflict in their needs. You might have two extensions and want the tabs hidden by one of them to not show in recent tabs until unhidden / unstashed (say, Tab Stash extension), and tabs hidden by the other extension to be switchable (say, Simple tab groups).

I don't know of any extension that requires hidden tabs to be hidden. There aren't even really extensions that require hidden tabs to not be hidden. There are just extensions that some users might have an easier time using if hidden tabs are not hidden from every view. Insofar as the preference is exposed by browserSettings, its value can be constrained such that it can only be set to true but not to false.

In other words, an extension that matches the use case we're discussing could choose to enable the pref, but could not choose to disable it. Only the user could disable it, manually. So, each extension installed will either not care about the pref or will want it enabled, eliminating the possibility of a conflict.

So probably a per-tab setting in addition to the hidden setting.

I mentioned that the tab object could be extended so that extensions can define the hiddenness of individual tabs, but this is a really clunky way to solve a pretty trivial issue. Also, it actually could create conflicts where extension 1 sets true and extension 2 sets false, unless we also applied the same kind of constraint to that implementation. I think between the available options, a preference is fitting. And to make the changes more accessible, we can take the new BrowserSetting idea under consideration too.

I think it won't suffice if we make it so only extensions can control this behavior. After all, it's the users who are having trouble, not the extensions. The extensions don't really care about the ctrlTab panel or any other view. Simple Tab Groups doesn't know or care whether a tab is shown in the ctrlTab panel. It's just that because it hides tabs, if you're using it, there's a good chance that you'd like to be able to easily unhide tabs. But there's also a chance that you don't want those tabs cluttering your ctrlTab panel. It's not necessary for the extension to function, but it may be important to some users.

So, no matter how we choose to implement this, I don't think many extensions would even interact with it. It's peripheral for them. And Simple Tab Groups, for example, probably isn't going to want to overstep its bounds by deciding where hidden tabs should be shown, because it's so peripheral. But users of Simple Tab Groups are likely to have strong opinions about where hidden tabs should be shown, independent of the extension but because they use the extension. So it's not necessarily a decision the add-on developer should make for the user.

None of this has any effect on people who don't use one of the add-ons in question. Once you install one of these add-ons, that creates this point of contention. Some people who use Simple Tab Groups may want those tabs hidden. Some people may not want those tabs hidden. It's conceivable that the extension could expose its own option for the user, but that's unlikely to resolve all complaints about the variety of extensions that hide tabs, some of which don't seem to be actively developed. So rather than this being a choice for extensions to make, this seems like a choice that extensions will create, but users have to make.

Giving addons the possibility to choose for the user could be useful for some minority of extensions that have a more narrow function. But for the vast majority of extensions that hide tabs, it's gonna be the user who wants to decide if hidden tabs should be displayed in some view or not. So, the nice thing about pref + BrowserSetting is that the browserSettings API works on internal Firefox prefs. So the user can set them, and an extension can set them in the unlikely event that it really cares about that particular behavior.

If for some reason we couldn't do a pref + browserSettings implementation, imo it would make more sense to just undo the changes. Logically I get that hidden tabs should be hidden, that is a no-brainer. But hidden tabs, though implemented internally, are completely unused in Firefox. The only way for a user to hide a tab without using the browser console is through an extension. So we're already talking about a particular set of applications. And although I can imagine lots of potential use cases for the feature, it seems like it's overwhelmingly used by tab organization extensions that greatly extend functionality to improve productivity.

Hiding hidden tabs from the ctrlTab panel strikes me as a cosmetic change, and although from my POV it's a logical and clean change, I don't ordinarily use extensions that use the hidden tabs feature. So it seems like a cosmetic change that won't really have any impact for the user unless it's changing the behavior of various productivity add-ons. And considering that, it seems like there's a high likelihood that users who actually encounter hidden tabs can be annoyed by the change. Everyone else will not even notice it because they can't hide tabs in the first place. And those who are using hidden tabs may be annoyed that they can't access those tabs anymore.

If Firefox had a context menu item like "Hide Tab" or something along those lines, I would definitely agree with the change and I wouldn't think this is a very high priority really. It's a pretty marginal thing either way. But because this is a feature that's only consumed by specific extensions, and those extensions are heavily geared toward power users trying to extend their abilities and speed up their activities, I think it should be catered toward productivity rather than aesthetics or even consistency.

We're also not being entirely consistent anyway, because hidden tabs are not hidden from any other views either. For example, they still appear in the recently closed tabs list. And removing them from that list might be tempting, but it leads to another inconsistency concerning what happens when you use the undo close tab command. If the most recently closed tab was a hidden tab, then does the undo close tab command open it, even though it's not in the list (and even though the list suggests the same keyboard shortcut will restore a different tab, i.e., the most recent unhidden tab)? Or do both the list and the command skip over it, making it impossible to restore tabs that were hidden?

It's also troublesome because tabs don't preserve their hiddenness. I haven't looked carefully at why that is, it's a bit odd since tab states have a hidden property. But it's always false for some reason, even if you hide tab > remove tab > collect state. So that would have to be fixed for any of the above to work anyway. But even if fixed, it begs the question how should hidden tabs be restored? Normally, restoring a tab selects it. But selecting a tab unhides it. So should we not select a restored hidden tab?

At that point it just seems like much ado about nothing. Hiding tabs shouldn't put them beyond reach. Otherwise there's no point in having the feature at all, since it's no different from removing a tab. A removed tab's state can still be preserved in the session store, after all. From my point of view, the basic purposes of hiding a tab are 1) so it won't clutter the built-in tab strip; 2) so extensions can use the property to stop it from cluttering their third-party tab views; and 3) so extensions can use it for organizational purposes, like tab grouping. So in that sense I think hiddenness should have very minimal effects, hiding the tab in the main view but leaving the rest to extensions.

I don't think we should read too much into the word hidden as though a hidden tab not being hidden in all views constitutes a bug. I'm more happy about this change than the prospect of hiding hidden tabs from every view, because the ctrlTab panel has quite limited room, and because we can limit the impact with a preference. But I still think it would be best to lean toward the minimal approach in this case too.

I would be happy to work on that if it's practical, but I couldn't get behind adding a new property to the tab and tab state prototypes just for this marginal feature that requires third party add-ons to even see. I would much rather support pref + BrowserSetting, even if there was the possibility of conflict. After all, there are many BrowserSettings that extensions can conflict on. That wasn't seen as reason not to implement them. It's just a limitation of the feature. But I mentioned before, there's a possibility in this case to eliminate the risk of conflict, by virtue of the probability that extensions that care about the pref would only ever want to enable it, not disable it.

Also, probably move this bug to the WebExtensions component for some feedback?

The pref would be the bulk of the implementation and would need to come first, so I'd rather sort that out first. If the BrowserSetting is agreed on we can just submit a child revision for that. Any changes to the API will merit further discussion anyway so that can wait much longer. But we can resolve the user complaints quickly in a way that's compatible with future API changes by adding a new pref.

So that's a lot of textual response, I hope I could understand everything. I think breaking the text and replying to individual pieces would be the best for me to start this discussion.

I'm not sure I understand how a per-extension setting would work. Extensions are installed simultaneously and are managing the same set of tabs.

Extensions would hide tabs using the Tabs API like they're doing now. They'll be able to "tell" Firefox whether hiding the tab should hide it also from the ctrlTab popup, (potentially from other places too??). To avoid conflict probably this needs to be allowed only at the time of hiding tabs, maybe as a parameter. It could also be implemented as a Tab property that could be set by extensions. In this case, you might say that it would be possible for 2 extensions to interfere with each other by changing the property visibleInCtrlTabPopup (for example) of a specific Tab. However, I'm not sure they would interfere because I don't think that (1) a 2nd extension would like to hide an already hidden tab and (2) an extension would like to (or should be able to) hide a tab from ctrlTab popup without the tab being a hidden tab. So essentially 1 tab would have to be hidden by a single extension at a time, and that only that extension should take care about whether that specific Tab is visible in ctrlTab popup or not.

I don't know of any extension that requires hidden tabs to be hidden.

Not sure what you mean by "requires"... Extensions that hide tabs do want the tabs to be hidden. From somewhere. Currently they can't specify from where. So they probably assume the current behavior of hideTabs() API.

The hiding tabs feature is currently a feature meant only for extensions, so I believe that extensions (and their authors) have something specific in mind when developing/hiding a tab and should definitely have a voice in deciding whether a tab should be hidden and (probably??) should also have a voice from where a tab will be hidden. Whether users would also have their own voice/preference and be able to override the preference (request??) of the extension is a different (important??) topic.

Furthermore, the change made in bug 1731050 was made due to the fact that the extension Tab Stash wanted to hide the tabs. Before the change in bug 1731050, the user would explicitly use Tab Stash to hide the tab. After that, the user could still access the tab from the ctrlTab popup and could activate/unhide that tab from there. In other words, the user could unhide the tab from somewhere else, a different place which is not the extension, while the extension could rely on the fact that the tab was still hidden.

Note that the change made in bug 1731050 was made due to the assumption that hiding tabs is inherently an extension-only feature and unhiding tabs should've also been an inherently extension-only feature. Due to this assumption, the possibility of the user unhiding the tab through the ctrlTab popup was considered a bug (that was fixed). A simple state - if you want to hide tabs, you do it only from one place - extensions. If you want to show the tabs, you do it only from one place - extensions (preferably the same one).

Before the change was made in bug 1731050, the ctrlTab popup was polluted with tabs that were meant to be stashed/hidden. The user, who wanted to hide these tabs, could no longer use the recent tabs popup without seeing the tabs he wanted to be hidden. The tabs he wanted to be hidden were taking the place of tabs that were not hidden. See the history of bug 1731050 for more info.

My understanding is that the users of the extensions like Simple Tab groups and Panorama tab groups were enjoying a semi-bug semi-feature. These extensions have their own official built-in ways of changing between the tab groups / different contexts like "Work" or "Home" through their own UI. They can also use a keyboard shortcut in addition to that in order to change between two recent groups for example, if they want to. Unfortunately, they cannot use Ctrl + Tab as such a shortcut. I can see where their users' requests are coming from though.

There aren't even really extensions that require hidden tabs to not be hidden.

I also believe that if an extension wants to hide a tab, it doesn't want it to not be hidden. However, some users of the extensions like Simple Tab groups and Panorama tab groups actually do want to be able to continue to access their hidden tabs from the ctrlTab popup. That's what this bug is all about, isn't it?

There are just extensions that some users might have an easier time using if hidden tabs are not hidden from every view.

This was not taken into account while fixing bug 1731050 as it was thought that unhiding tabs was an extension-only feature. Probably it was a mistake not to take it into account. Mistakes have to be repaired the correct way. WebExtensions Mozilla employees should clarify how that API is really supposed to work before it can be fixed the correct way this time. Better late than never.

Insofar as the preference is exposed by browserSettings, its value can be constrained such that it can only be set to true but not to false.

Again we're coming into the land of conflicts between extensions' needs. We're probably already into that conflict, according to the users of extensions like Simple Tab groups and Panorama tab groups.

browserSettings are global, if an extension sets browserSettings to pleaseHideTheHiddenTabsFromCtrlTab = true, users of extensions like Simple Tab groups and Panorama tab groups would not see any change. I don't say that they have to be able to continue using ctrlTab to access hidden tabs, although historically Firefox was much about customization.

Setting browserSettings to pleaseHideTheHiddenTabsFromCtrlTab = false on the other hand essentially reverts the fix in 1731050, which means there are other extensions like Tab Stash that can't really say where they want to hide the tabs from. For them this would mean that (1) switching between contexts like "Home" and "Work" would not be a clear switch because of the ctrlTab popup pollution. (2) It would also mean that we assume and officially declare that hiding tabs is not an extension-only feature.

In other words, an extension that matches the use case we're discussing could choose to enable the pref, but could not choose to disable it. Only the user could disable it, manually.

I'm all in for allowing the user to override whatever he wants, if he knows what he's doing. I'm still worried about global browser settings now.
As far as I understand what you propose is an about:config pref that allows the user to enable or disable hidden tabs in ctrlTab popup, and additionally to expose it to the extensions? So they can only choose to globally not show the hidden tabs in the ctrTab popup if there is at least one extension that doesn't want to show them in the popup?

I mentioned that the tab object could be extended so that extensions can define the hiddenness of individual tabs, but this is a really clunky way

Definitely more work in more areas of the browser. Plus I'm not used to the Firefox codebase outside of the frontend popup.

And to make the changes more accessible, we can take the new BrowserSetting idea under consideration too.

If you mean exposing the about:config preference to about:preferences - okay.

Giving addons the possibility to choose for the user could be useful for some minority of extensions that have a more narrow function.

I don't have anything against the user overriding the extensions' choices. I'm not sure if not allowing extensions to show or hide tabs in the ctrlTab popup is bad or not bad. I can say that before bug 1731050 it was bad, and after that bug there were some users who didn't like the other way.

no matter how we choose to implement this, I don't think many extensions would even interact with it. It's peripheral for them.

From the extension point of view, I believe hiding the hidden tabs from ctrlTab popups is the natural way they expect it to be. Showing the tabs would be only a preference of some users. In my opinion.

From my point of view, the basic purposes of hiding a tab are

  1. Hide and discard tab makes you continue on restore from correct scroll position, with correct text field inputs and with the back arrow history kept... like the Tab stash feature of Microsoft Edge.

Hiding tabs shouldn't put them beyond reach.

They're not beyond reach, they're hidden. They have a place in the "All tabs" near the "New tab" button. There's also intro to this feature the first time a tab is hidden by an extension...

A simple state - if you want to hide tabs, you do it only from one place - extensions. If you want to show the tabs, you do it only from one place - extensions (preferably the same one).

It seems like you're only imagining use cases where the user hides tabs explicitly, but that's not how most extensions seem to use the feature. Other extensions hide tabs on their own, not to get rid of them but to group them under an unhidden tab, to make space in the horizontal tab strip. It seems very unreasonable to make users of those extensions go to all the trouble of manually opening the all tabs panel and locating the hidden tab they want to unhide. It's making Tab Stash's third-party behavior seem more cogent at the expense of users of tab organization add-ons like Simple Tab Groups (which by itself has more users than Tab Stash has).

Simple Tab Groups users have already expressed dissatisfaction with the changes, and it's easy to see why (I actually use Tab Stash and don't use STG or any other tab grouping extension, but it's obvious why this is such an imposition on tab grouping extension users). These are fundamentally different uses of the "hide tab" feature. I don't see why we are privileging Tab Stash over the tab organization extensions. Especially because Tab Stash also supports removing tabs and backing them up rather than hiding them, since hiding them doesn't have much effect on resource usage. Seems like most other extensions that backup and restore tabs do it that way too. I can see why you're conflating the "hide tab" and "remove tab" features, since within Tab Stash, they're presented as different approaches to do the same thing. But there are tons of extensions that don't use the hide tab feature in this way at all.

I said before how the hide tab feature serves no purpose if it functions like the remove tab feature. The point of hiding a tab isn't to get rid of it so it can be restored later. That's the point of the remove tab feature. So this seems more like a Tab Stash problem than a Firefox problem. But I can see an argument for giving the user (and possibly the add-on) control over this choice, since clearly we have multiple conflicting use cases.

My understanding is that the users of the extensions like Simple Tab groups and Panorama tab groups were enjoying a semi-bug semi-feature.

It's baffling how you interpret this as some kind of bug exploit, yet interpret Tab Stash's conflating "hide tab" with "remove tab" as the intended purpose of the hide tab feature, such that you assume it was accidental that hidden tabs are only elided from the tab strip. This is just an assumption without any basis. I saw your comments about "enjoying a bug" in element, but there's no way to know that without asking whoever wrote the code, and I don't think it'd be of any consequence anyway.

I said before I don't think we should interpret "hidden" as meaning "hidden everywhere." So, not hiding hidden tabs from every view is not a bug. It's not self-evident that a tab that's hidden in the tab strip should be hidden everywhere. It may seem intuitive to you, as a Tab Stash user, but clearly it bothers other users. And if it is a bug in the ctrlTab panel, then it's a bug in session store too, but like I said, "fixing" that would do more damage.

And as for the all tabs panel, hidden tabs are only hidden from it because in that case we can make a second TabsPanel view for showing hidden tabs and add a subview button to the main view. We can't make a second ctrlTab panel. It can only be opened by keyboard shortcut. So unlike the decision to split visible tabs and hidden tabs between two different TabsPanel views, this ctrlTab change didn't add a new view to move the functionality over to. It just removed the functionality altogether. So it's a very opinionated change I think.

If you mean exposing the about:config preference to about:preferences - okay.

browserSettings is a WebExtensions API. It's a system by which extensions can control global preferences. That could lift the burden on users to know about obscure preferences if they're using an extension that actually cares about what is shown in the ctrlTab panel and wants to make such a decision for the user. Clearly not every extension should be making a unilateral decision like that, since already users have complained that they don't want tabs to be hidden from the ctrlTab panel.

Exposing that preference in about:preferences would be unreasonable, since the pref is so obscure and marginal in its scope. Most users won't even know what "hidden tabs" means, since Firefox doesn't hide tabs on its own. That kind of preference can only have an effect if the user has an extension installed with a particular permission, and it's definitely not worth wiring up a check for that in the preferences code. And even if we did, it's just not an important enough preference to clutter up the UI. So, that's why associating it with extensions might make sense.

They're not beyond reach, they're hidden. They have a place in the "All tabs" near the "New tab" button. There's also intro to this feature the first time a tab is hidden by an extension...

Exactly. My whole point is that hidden tabs are not supposed to be hidden from every view. I gave other examples as well. As far as I can tell, they were only hidden from the tab strip (and the all tabs main view, but that was sensible because the hidden tabs could be displayed in a subview instead). So why hide them from the ctrlTab panel, especially if more users are complaining about it than advocating for it? At the very least we should put this in the hands of the user.

By the way, it sounds like you're saying the all tabs panel somehow substitutes for what was lost as a result of this change. But that can't be right, since Ctrl+Tab is a keyboard shortcut that is very fast and easy to use. The all tabs panel isn't designed for quickly jumping between recent tabs; it's designed for making it easier to find tabs when you have so many that the tab strip is overflowing. So it makes sense that users quickly complained about losing the ability to access hidden tabs with the Ctrl+Tab shortcut.

It seems like you're only imagining use cases where the user hides tabs explicitly

Yes, either through the tab's context menus or through some functionality inside the extensions' UI.

It seems very unreasonable to make users of those extensions go to all the trouble of manually opening the all tabs panel and locating the hidden tab they want to unhide.

They don't have to do that. The extensions have explicit functionality in their UI to change/activate/unhide tabs. Probably also can be done with keyboard shortcuts even faster. My take for the "All tabs" -> "Hidden tabs" list is that it's there not for regular use, but so that users are able to override the extension for whatever reasons.

Other extensions hide tabs on their own, not to get rid of them but to group them under an unhidden tab

That's essentially what extensions like Simple Tab groups and Panorama tab groups are doing, right? I tried them and reproduced both with builds before and after the bug 1731050 fix what the users were capable of doing with the ctrlTab switcher. I get where they come from. I was up for fixing this from the moment I reproduced it.
I reproduced it right after Marco Trevisan wrote about it in the other bug. Before that I was waiting for explicit STR, but after that I decided to actually try to see what the real problem was.

These are fundamentally different uses of the "hide tab" feature.

I don't think it's fundamentally different, it's essentially the same but for different places for hiding tabs.

I don't see why we are privileging Tab Stash over the tab organization extensions.

Because when bug 1731050 was fixed I didn't happen to know that there were actually extensions that were listening explicitly to tab URL changes and were hiding and unhiding groups of tabs based on the active tab. That's what I think Simple tab groups is doing in this case. That's in addition to the way of changing between tab groups using buttons in extensions' UI. Also, no one filed a bug during Nightly and Beta, otherwise, I'm pretty sure it wouldn't have shipped into Release the way it works now.

Especially because Tab Stash also supports removing tabs and backing them up rather than hiding them, since hiding them doesn't have much effect on resource usage.

On it's own it doesn't have an effect on resource usage. But when combined with the tab discard feature (which Tab Stash has explicit options for) it allows for (1) minimising resource usage of the tab, (2) remembering the back arrow history, (3) Remembering the current scroll position while (4) hiding the tab for later. That's powerful feature and use-case.

I can see why you're conflating the "hide tab" and "remove tab" features

I said before how the hide tab feature serves no purpose if it functions like the remove tab feature.

I'm not sure what/if I'm conflating them. For me, the distinction is that the above 4 functions don't work when a tab is removed. For me, removing a tab is the same as closing it, isn't it? Closing loses all context, hiding does not. So it's definitely different.

The point of hiding a tab isn't to get rid of it so it can be restored later.

I don't get it... you hide it and you unhide it. It's not getting rid of it. It's keeping it away from your eyes for whatever reason you want to - call it grouping / stashing... grouping is essentially stashing groups of tabs at whatever time you want to. Closing the tab is what I think means to get rid of that tab.

But I can see an argument for giving the user (and possibly the add-on) control over this choice, since clearly we have multiple conflicting use cases.

If the solution you're proposing would allow the user to somehow enroll his own choice into showing the tabs into the ctrlTab popup or not show them, I'm up for it. It's not okay for me to remove the changes in bug 1731050, but I'm in for making them optional. The default could be the after 1731050 way, or the way it worked before.

I don't think it's a good user experience to pollute the recent tabs popup with tabs that are all out of context (for example "Work" vs "Home").

At the very least we should put this in the hands of the user.

+1 for a user / extension choice.

By the way, it sounds like you're saying the all tabs panel somehow substitutes for what was lost as a result of this change.

No. My take as I said is that the all tabs panel is for exceptional situations/usage. All I'm trying to say is that users are used to something that is controversial. If I had to keep it the way it is after bug 1731050, I would instead rely on UI functionality of the extension/its own buttons and on custom keyboard shortcuts for extension actions like change to most recent group. Not on the "All tabs" list.

First of all I apologize because I did not understand all the detailed stuff, but I appreciate the effort since I am one of the complaining users in bug 1731050. I also like the idea of a user choice, supporting users in both positions (before and after that bug). I think an about:config pref is ok, since addons users may tend to be somehow tweakers and should know what they are doing. I don't think an official preference or setting is appropriate.
Finally, letting extensions developers control the situation is not ideal, because they may not prioritize the change at all, and we may be left with the "broken" extension for a long time.

Thank you all.

You need to log in before you can comment on or make changes to this bug.