If bug 1332447 or bug 1384515 land then we'll have a scenario where tabs can be hidden and key security or elements of the tab interface are no longer shown to a user. Whilst some of these might be merely annoyances, some might be serious security or privacy issues. This bug is to track all those things and should be considered a blocker to allowing those APIs to land without the user being able to set some explicit flag, eg: turn on a preference.

I'm leaving this for UX, but for other parts of WebExtensions we've tried to show, not only what change has occurred, but the add-on that is responsible for it. I'm not sure how this would manifest itself in this case: * would we show all add-ons that manage tabs * would we need to show which add-on hid tabs * would we need to provide disabling of those add-ons in the notification?

From my experience: > * would we show all add-ons that manage tabs No. Hiding tabs creates a more complex level of requirements and limitations and powers over the browser user. In my opinion, this should be a new permission. The same way as there's a permission for "downloads.open", this would be "tabs.fullControl" or "tabs.hide" kind of name (I'm not good with names). > * would we need to show which add-on hid tabs IMO, just in the console, in the appropriate tab. However, the browser should keep track of who hid which tab so that, if the extension is disabled, the tabs that were hidden are automatically shown when the addon is not installed. Any comments?

Oh! For the permission, it could be used "tabs.management". That's another possible name.

One suggestion, is to expand the all tabs button. This currently only appears on overflow of the tab strip. We could make it appear if there is an overflow or a hidden tab. We would add notifications for being audible or webRTC recording (or other methods) to the button and the drop down. Since this element already exists and is supported it would be good to expand and would improve Firefox in general. This wouldn't work too well when the entire tab strip is hidden though.

I am working on this. Here is the prototype I shared in our last meeting: https://mozilla.invisionapp.com/share/82EIATQAF#/266445458_Project_Jazz_-_Tab_Hiding_-_Install_Extension (It will be updated as we detail the behavior we want)

I like it quite much. I added my comments on the pages themselves. Highlights: -> Menu placement, I prefer option 1; replace the downward arrow(?) with the tab symbol. -> Telling which extensions are hiding; I rather if you use a list or, at least, you place the extension's name in quotes. The list, IMO, is better to make it more readable also because multiple extensions may be hiding tabs. -> When hidden tab uses sound --> Don't change the icon periodically between the tab icon and sound. IMO, the mixed icon (option 2) is the best choice. Animations call attention and, for something like this, a continuous call for attention can be annoying. --> Great idea in making it appear in its own list below the hidden tabs collapse list (unsure how to call that). I like that quite much.

I notice that this is filed under the WebExtensions component but I'd like to point out that my main profile has many tabs (hundreds!) that were hidden by the Tab Groups addon (ie in other groups) before the upgrade to Firefox 57 disabled it. They are still hidden and the only in-browser way I've found to access them is the "Switch to tab" feature of the address bar, but that requires me to remember something about every such tab. I hope this situation can be kept in mind during the implementation of this UI because I can imagine other users may be in the same situation with tabs that were hidden by something other than a WebExtension.

(In reply to Will Elwood (:Will) from comment #7) > I notice that this is filed under the WebExtensions component but I'd like > to point out that my main profile has many tabs (hundreds!) that were hidden > by the Tab Groups addon (ie in other groups) before the upgrade to Firefox > 57 disabled it. > > They are still hidden and the only in-browser way I've found to access them > is the "Switch to tab" feature of the address bar, but that requires me to > remember something about every such tab. I hope this situation can be kept > in mind during the implementation of this UI because I can imagine other > users may be in the same situation with tabs that were hidden by something > other than a WebExtension. We are working on a UI that would allow users access to all hidden tabs, no matter what extension hid them. So I would hope this would also solve your problem.

Dao, I'm starting to work on this, would you be a good person to review my changes? The mocks linked in comment 5 show a photon-style dropdown, but this menu is currently a platform-specific dropdown. I have an initial patch to show hidden tabs in the current dropdown and it isn't too big. I will likely move forward with this patch initially. The all tabs menu also has options for opening tabs in containers or a recently closed tab. These seem like they should move to the new tab button to me (and they aren't included in the mocks here). If I were to convert the all tabs dropdown to photon styling and move the other options around is there anything you would suggest for doing this?

(In reply to Mark Striemer [:mstriemer] from comment #9) > Dao, I'm starting to work on this, would you be a good person to review my > changes? Yeah, I can do that. > The mocks linked in comment 5 show a photon-style dropdown, but this menu is > currently a platform-specific dropdown. I have an initial patch to show > hidden tabs in the current dropdown and it isn't too big. I will likely move > forward with this patch initially. > > The all tabs menu also has options for opening tabs in containers or a > recently closed tab. These seem like they should move to the new tab button > to me (and they aren't included in the mocks here). > > If I were to convert the all tabs dropdown to photon styling and move the > other options around is there anything you would suggest for doing this? I feel like this should be broken up up into a couple of steps that could land separately: 1. expose hidden tabs to the existing menu 2. show the button when there are hidden tabs (the button currently shows only when tabs overflow) 3. change the button's icon 4. convert the menu to an arrow panel

What API is being made and/or what API exists so that an extension can re-hide a tab that was shown due to a forceful tab unhide (as demonstrated here https://mozilla.invisionapp.com/share/82EIATQAF#/screens/266445451 )? One major use-case would be allowing the user to handle the event (E.g. filling and submitting the HTTP auth form) and then return the user to the tab he was before, while re-hiding the tab that requested attention. I see some attributes that can be used, such as getting the user's current focused tab but I'm missing API such as knowing which tab the user was at before he was forcefully changed to the tab that required attention. Additionally, if two consecutive (or even more) tabs require attention in a sequence, how can an extension handle such event? E.g. Tabs 20-50 are hidden. User is in Tab 2. In tab 30, auth is required. -> User is sent to tab 30 to fill the form. While user is in tab 30, tabs 31-36 reload and also require a basic auth form submission. The extension's priority is to re-hide tabs 30-36 and return the user to tab 2 as soon as all those events are handled. With the expected API, how can such use-case be fulfilled?

I'm not sure if an event or something is being added but I think if you're having 7 tabs all ask for HTTP auth at the same time you're going to be in a world of pain whether they're hidden or not. Shane has been doing the API work and likely knows more than me about how this might be handled. I'll NI him as well. I think the idea is that it's up to the user to hide the force shown tab again. If the user manually hid the individual tab they would hide it again, if they were in a tab group style situation they could activate that tab group again. As for getting back to the last active tab, I'm not quite sure how to do that. If you were in the middle of 100 open tabs that could be quite difficult to do manually.

Basically we'll ensure the tab is shown for any window-modal dialog that we cannot delay somehow. There will intentionally be no smarts built around this as there are too many ways to get it wrong, and how it works will all change down the road.

Hi, as simple user, I have no clear idea on the details of implementation of this feature. But, for instance, if several pages show popups, as HTML element, it is expected to treat them when the user activates the pages again, meaning when the users comes back to the page tab if shown in the current displayed group, or when tab's group is switched to, and displayed, and the user activates the tab in question. Same, for some other modal dialogs (although I can't imagine what kind of dialog should be). Like a browser message popup or dialog? I saw Chrome popping up messages that are not HTML elements. This kind is right, from my point of view, to be treated as above too. I don't speak for others, though. So, for the most delicate scenario, I would notify in a non-distracting way, some notification (maybe notification list) similar to the current burger menu notifications, with some bubble, telling some page requests attention (ideally treatable by some add-in too). Just my user thoughts.

(In reply to brunoais from comment #11) > What API is being made and/or what API exists so that an extension can > re-hide a tab that was shown due to a forceful tab unhide (as demonstrated > here https://mozilla.invisionapp.com/share/82EIATQAF#/screens/266445451 )? > > One major use-case would be allowing the user to handle the event (E.g. > filling and submitting the HTTP auth form) and then return the user to the > tab he was before, while re-hiding the tab that requested attention. I kinda recall we had discussed something like that in one of the huge-threads, when talking about onbeforeunload events.