1332447 - API to hide the tabstrip

Status: NEW

(WebExtensions :: Frontend, enhancement, P3)

Description

[Tim Nguyen :ntim]

Since WebExtensions are unlikely going to support hiding built-in toolbars (since toolbar IDs may change with updates and stuff), I think it makes sense to support a built-in way to hide the navigation bar and the tab bar.

It will open up to a bunch of possibilities: an add-on could re-implement the tab bar with more powerful functions using the toolbar and tab APIs. Or maybe an add-on could implement an IE-9 like one-liner UI. In these cases it makes sense to provide a way to hide the built-in tab bar. 

If I recall correctly, the functionality was removed because some people accidentally hid their tabbar/navigation bar, but as far as I know, that's because they could accidentally hide it from the navigation bar context menu.

So UX wise, I suggest that the navigation bar context menu still hides this option, but that the "Toolbars" menu in the customization mode provides this option. As far as I know, accidental triggering of the customization mode happens much less often than the accidental triggering of the navigation bar context menu.

Or if a toolbar add-on is detected, the customization mode could reveal those options, although that would be confusing.

Comment 1

[Andy McKay]

I think the ability to hide these elements could be exposed as a WebExtension API. A common use case, with lots of rabid users is a vertical tab solution. We are providing an API to allow sidebars, so an extension could provide there own tab implementation in HTML and JS... but they would need to hide the existing tabs. 

People have told me that hiding the tabs also removes a lot of the events because those are tied to the XUL. 

A vertical tab solution is on the WebExtension list of add-ons we'd like to have support for, so interested in that one.

Comment 2

[:Gijs (he/him)]

(In reply to Andy McKay [:andym] from comment #1)
> People have told me that hiding the tabs also removes a lot of the events
> because those are tied to the XUL. 

Hiding the navigation toolbar does the same thing - it breaks a bunch of builtin Firefox features (cf. bug 1227540 + dupes), and we unshipped the "open location" dialog so if the navigation toolbar is hidden, the user can't use the location bar to navigate (and therefore various other things break, like the page permissions notifications which are anchored in the location bar).

Comment 3

[Croydon]

I rely on that in order to port Vertical Tabs Reloaded.

Comment 4

[Tim Nguyen :ntim]

Attachment: Proposal

Shane, can you take a look at this proposal?

It covers:
- Moving built-in toolbars around
- Hiding built-in toolbars
- Registering new toolbars

Comment 5

[Tim Nguyen :ntim]

I'm very bad at naming, perhaps "browser_region_tweak" could be named in a better way.

Comment 6

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8841190 [details]
Proposal

I think this is a good start on a definition of what would be wanted, and what issues or limitations should be in place.  Whether it is a manifest addition or an api is less important right now.

What about showing something that is hidden (e.g. Personal Toolbar)?

I think hiding the navbar is off the table for now.  We probably need a good grasp on what breaks if the tabstrip is hidden, it would help to understand the feasibility of providing a way to hide it.

browser_region - This feels like a CustomizableUI widget, though with an ability to be in locations not supported by CUI.  The other day I was pondering that an iframe CUI widget might be a solution for toolbars, and that maybe new toolbars are *not* allowed to be added, but that the Personal Toolbar could somehow be shown.  Addons could choose to place more interesting widgets (using the iframe CUI widget) into the personal toolbar.

default_block_size - this could just be height and width.  But is this handled by the theme api?

customizable - I'm not certain we would ever allow it to NOT be customizable, so the user could choose to hide/remove individual items.

Don't recall if I mentioned this to you: https://github.com/mixedpuppy/web-ext-panels

Comment 7

[Kris Maglione [:kmag]]

(In reply to :Gijs (away until Feb 27) from comment #2)
> Hiding the navigation toolbar does the same thing - it breaks a bunch of
> builtin Firefox features (cf. bug 1227540 + dupes), and we unshipped the
> "open location" dialog so if the navigation toolbar is hidden, the user
> can't use the location bar to navigate (and therefore various other things
> break, like the page permissions notifications which are anchored in the
> location bar).

We do currently support opening windows without tab strips or a location bar, and we hide both in full screen mode, so these are issues we should fix in any case.

For the case of focusing the location bar when it's hidden (via Ctrl+L/⌘-L or similar), we should probably just use similar auto-hiding behavior to what we do for the hidden menu bar and the location bar in full screen mode. For notifications, we may be able to come up with something better.

Comment 8

[Tim Nguyen :ntim]

(In reply to Shane Caraveo (:mixedpuppy) from comment #6)
> Comment on attachment 8841190 [details]
> Proposal
> 
> I think this is a good start on a definition of what would be wanted, and
> what issues or limitations should be in place.  Whether it is a manifest
> addition or an api is less important right now.
> 
> What about showing something that is hidden (e.g. Personal Toolbar)?
We could do either:
- Show on install, and if the user hides it manually, it stays hidden (eg. simply toggle on the pref that hides the personal toolbar on install)
- Disable the menu item to hide it, and say it was hidden by an add-on somehow
- Not support showing/hiding toolbars which the hidden state is controlled by the browser (find-bar/personal toolbar)
Initially we could limit this to hiding the tabbar (the most common use-case for this), once that's done, we can think out the details for other toolbars.

> browser_region - This feels like a CustomizableUI widget, though with an
> ability to be in locations not supported by CUI.  The other day I was
> pondering that an iframe CUI widget might be a solution for toolbars, and
> that maybe new toolbars are *not* allowed to be added, but that the Personal
> Toolbar could somehow be shown.  Addons could choose to place more
> interesting widgets (using the iframe CUI widget) into the personal toolbar.
This is what I suggested in bug 1320581.

> default_block_size - this could just be height and width.  But is this
> handled by the theme api?
For the toolbar, it will take up the browser width. As for the sidebar, it will take up the browser height. 

default_block_size is for flexibility on the height in case of the toolbar, or the width in case of the sidebar.

> customizable - I'm not certain we would ever allow it to NOT be
> customizable, so the user could choose to hide/remove individual items.
Right, the url field is probably enough to control this.

> Don't recall if I mentioned this to you:
> https://github.com/mixedpuppy/web-ext-panels
Nice! It seems to cover what I had in mind for browser_region. One suggestion though: if there's no URL set on the panel, the panel could simply act as a CustomizableUI region.

I think support for customizable toolbars is really important as a lot of people as using CTR for the add-on bar, and Status-4-Evar to get a status bar back.

Comment 9

[:Gijs (he/him)]

(In reply to Kris Maglione [:kmag] from comment #7)
> (In reply to :Gijs (away until Feb 27) from comment #2)
> > Hiding the navigation toolbar does the same thing - it breaks a bunch of
> > builtin Firefox features (cf. bug 1227540 + dupes), and we unshipped the
> > "open location" dialog so if the navigation toolbar is hidden, the user
> > can't use the location bar to navigate (and therefore various other things
> > break, like the page permissions notifications which are anchored in the
> > location bar).
> 
> We do currently support opening windows without tab strips or a location
> bar, and we hide both in full screen mode, so these are issues we should fix
> in any case.

No, no they're not. We don't support opening windows without a location bar. We support opening windows without a fullscale navbar, which still shows a (readonly) location field, and which also doesn't exhibit a bunch of the problems associated with permanently hiding the entire #nav-bar element by virtue of the other buttons being hidden (so the anchors of popups that break when the navbar is hidden aren't visible in this case, and can't be *made* visible, whereas that *would* be possible in the cases we're talking about here).

> For the case of focusing the location bar when it's hidden (via Ctrl+L/⌘-L
> or similar), we should probably just use similar auto-hiding behavior to
> what we do for the hidden menu bar and the location bar in full screen mode.
> For notifications, we may be able to come up with something better.

This is really not trivial.

I'm very unhappy with this going ahead, if it does. We had a bunch of complexity around the navbar/tabstrip being hidden/unhidden at will, and got rid of most of it. Re-doing that work is unattractive in the extreme, probably has security issues (re-showing the navbar shouldn't *only* happen when accel-l is invoked - what about permission requests? What about other things the photon design relocates (back) into the navbar, like the bookmarks star?

Allowing add-ons to hide the navbar paints us back into a corner we're struggling to get out of. We shouldn't do it.

Comment 10

[Tim Nguyen :ntim]

(In reply to :Gijs from comment #9)
I think hiding the nav-bar is off the hook for now, since it contains sensitive security information.

Though, the minimum here should be hiding the tab bar, since add-ons like Tab Center rely on it.

Comment 11

[Andy McKay]

I think the call should be made by the Firefox front end team, because hiding the tab bar is something they'll have to maintain and support. If it happens the WebExtensions team will do whatever it can to help. So I'm looking at Gijs and team here, also should I move this bug somewhere else? Is there any more information we can provide as to why we think this will be a good idea?

Comment 12

[:Gijs (he/him)]

(In reply to Andy McKay [:andym] from comment #11)
> I think the call should be made by the Firefox front end team, because
> hiding the tab bar is something they'll have to maintain and support. If it
> happens the WebExtensions team will do whatever it can to help. So I'm
> looking at Gijs and team here, also should I move this bug somewhere else?
> Is there any more information we can provide as to why we think this will be
> a good idea?

I'm going to forward this to dolske. I think I understand reasonably well why we'd want to be able to hide the tabstrip (basically, vertical tabs and various other tab-strip-replacement add-ons, as well as minimalist-UI people who would prefer to lose as little vertical space as possible), but I also know that we're very resource-constrained right now so taking on more work isn't easy.

Hiding the tabstrip is less painful than hiding the navbar, so I think we could consider it, whereas the nav-bar is just... ugh. I don't know how hard maintaining it would be, exactly. I expect it would be an easier call if there was a commitment from the webextensions team to do some of that work.

Comment 13

[Johann Hofmann [:johannh]]

> Hiding the tabstrip is less painful than hiding the navbar, so I think we could consider it, whereas the nav-bar is just... ugh. I don't know how hard maintaining it would be, exactly. I expect it would be an easier call if there was a commitment from the webextensions team to do some of that work.

To be honest I think it's such a high maintenance cost that it can never be solved through commitment from the Webextensions team. Working on popup notifications we had (and still have) to make a lot of compromises to accommodate even small location bar changes through pageproxystate. Hiding the entire navbar will introduce an entire category of problems and edge cases to, frankly, waste engineering productivity (considering that, percentage-wise, a low number of users will benefit from this).

In addition to that I don't think we should trust Webextensions to hide/replace the site identity UI (especially without access to a ton of security internals like mixed content blocking or certificate override). This should not be subject to negotiation IMO.

Comment 14

[:Gijs (he/him)]

(In reply to Johann Hofmann [:johannh] from comment #13)
> > Hiding the tabstrip is less painful than hiding the navbar, so I think we could consider it, whereas the nav-bar is just... ugh. I don't know how hard maintaining it would be, exactly. I expect it would be an easier call if there was a commitment from the webextensions team to do some of that work.
> 
> To be honest I think it's such a high maintenance cost that it can never be
> solved through commitment from the Webextensions team. Working on popup
> notifications we had (and still have) to make a lot of compromises to
> accommodate even small location bar changes through pageproxystate. Hiding
> the entire navbar will introduce an entire category of problems and edge
> cases to, frankly, waste engineering productivity (considering that,
> percentage-wise, a low number of users will benefit from this).
> 
> In addition to that I don't think we should trust Webextensions to
> hide/replace the site identity UI (especially without access to a ton of
> security internals like mixed content blocking or certificate override).
> This should not be subject to negotiation IMO.

Sorry I was unclear. Here's the same thing, rewritten to reflect what I meant more accurately:

Hiding the tabstrip is less painful than hiding the navbar, so I think we could consider it, whereas the nav-bar is just... ugh. I don't know how hard maintaining [hiding the tabstrip] would be, exactly [, so it's hard for me / the fx frontend team to sign up to doing it]. I expect it would be an easier call if there was a commitment from the webextensions team to do some of that work.

Comment 15

[Johann Hofmann [:johannh]]

(In reply to :Gijs from comment #14)
> (In reply to Johann Hofmann [:johannh] from comment #13)
> > > Hiding the tabstrip is less painful than hiding the navbar, so I think we could consider it, whereas the nav-bar is just... ugh. I don't know how hard maintaining it would be, exactly. I expect it would be an easier call if there was a commitment from the webextensions team to do some of that work.
> > 
> > To be honest I think it's such a high maintenance cost that it can never be
> > solved through commitment from the Webextensions team. Working on popup
> > notifications we had (and still have) to make a lot of compromises to
> > accommodate even small location bar changes through pageproxystate. Hiding
> > the entire navbar will introduce an entire category of problems and edge
> > cases to, frankly, waste engineering productivity (considering that,
> > percentage-wise, a low number of users will benefit from this).
> > 
> > In addition to that I don't think we should trust Webextensions to
> > hide/replace the site identity UI (especially without access to a ton of
> > security internals like mixed content blocking or certificate override).
> > This should not be subject to negotiation IMO.
> 
> Sorry I was unclear. Here's the same thing, rewritten to reflect what I
> meant more accurately:
> 
> Hiding the tabstrip is less painful than hiding the navbar, so I think we
> could consider it, whereas the nav-bar is just... ugh. I don't know how hard
> maintaining [hiding the tabstrip] would be, exactly [, so it's hard for me /
> the fx frontend team to sign up to doing it]. I expect it would be an easier
> call if there was a commitment from the webextensions team to do some of
> that work.

Ah, I see. Thanks for the clarification! Yes, I agree with the above statement. Hiding the tabbar would be nice, but it's hard to say how much work it requires.

Comment 16

[Andy McKay]

I think we are all in agreement that the hiding the navigation bar wouldn't be a acceptable from a security point of view, so let's stop talking about that and stick to the tabs bar. Yup, the WebExtensions team will help.

Comment 17

[Dan Callahan [:callahad]]

FWIW, Devrel is frequently seeing this request, requests that would require this, and users presuming that such an API can be taken for granted. We'd be happy to help promote this API when implemented.

Comment 18

[Tim Nguyen :ntim]

Chrome has a chrome_ui_overrides manifest fields, though I don't really like it, because there's no support for dynamic changes (you can't hide the tabbar when there's only one tab, or do similar stuff like that).

https://developer.chrome.com/extensions/ui_override

Comment 19

[Croydon]

(In reply to Tim Nguyen :ntim from comment #18)
> Chrome has a chrome_ui_overrides manifest fields, though I don't really like
> it, because there's no support for dynamic changes (you can't hide the
> tabbar when there's only one tab, or do similar stuff like that).
> 
> https://developer.chrome.com/extensions/ui_override

Agreed. Something I dislike in many WE Apis: Manifest fields are way too restrictive in the way they can be used.

Comment 20

[Justin Dolske [:Dolske]]

I'm not sure I have anything useful to add here.

I don't have any general objection to an API to hide UI elements (like the tab strip), but it sounds like the real issue is when doing so causes other parts of Firefox to break because of the way things are implemented and assumptions that are made. 

More detail on exactly what is broken and how it would be fixed would seem like the next needed info here.

Comment 21

[Andy McKay]

I think we've got broad approval on this idea, based on the number of requests for tab changes. Now its just a matter of finding someone to work on it.

Comment 22

[Timothy Johnson]

Attachment: Collapse the tabs bar from manifest.

One possible way to sidestep most of (if not all of) the problems with hiding the tabs bar is to collapse it instead. In the collapsed state all events are still available but the toolbar isn't visible to the user. The only downside is that to keep the toolbar collapsed we have to use a MutationObserver. Can someone with more knowledge than me comment on whether or not that would be bad from a performance standpoint?

Comment 23

[Tim Nguyen :ntim]

I would prefer allowing a dynamic way of hiding toolbars rather than a static manifest way:

browser.toolbars.tabs.{get/set}Visible({ visible });

The API design is similar to browser.devtools.panels.(elements/...).

Comment 24

[Timothy Johnson]

That's what I was originally thinking (and would prefer) as well, I was just going off the proposal.

Comment 25

[Johann Hofmann [:johannh]]

Just wanted to add two things that we might need to solve when allowing extensions to hide the tab bar:

- Tabs are used to show the audio indicator that the user can use to mute the tab. That's a nice functionality and it would be useful to expose this to add-ons via e.g. the tabs API
- More importantly, tabs are used to highlight that a background tab is streaming a WebRTC connection, e.g. recording your camera or microphone. We would detriment user privacy by not at least giving tab extensions the ability to display that.

Again, I still think the general idea is good, I just wanted to make sure this is considered.

Comment 26

[u462496]

(In reply to Johann Hofmann [:johannh] from comment #25)
> Just wanted to add two things that we might need to solve when allowing
> extensions to hide the tab bar:
> 
> - Tabs are used to show the audio indicator that the user can use to mute
> the tab. That's a nice functionality and it would be useful to expose this
> to add-ons via e.g. the tabs API
> - More importantly, tabs are used to highlight that a background tab is
> streaming a WebRTC connection, e.g. recording your camera or microphone. We
> would detriment user privacy by not at least giving tab extensions the
> ability to display that.
> 
> Again, I still think the general idea is good, I just wanted to make sure
> this is considered.

In addition(??) to this, tabs now suspend the streaming/loading of audio when audio would normally start playing when a tab is opened in the background (eg youtube), and displays a playbutton icon which will begin the streaming.  I don't know if that is a separate API from the mute API, but I just want to make sure it is considered.

Comment 27

[Tim Nguyen :ntim]

(In reply to Timothy Johnson from comment #24)
> That's what I was originally thinking (and would prefer) as well, I was just
> going off the proposal.

The proposal was just a possible idea (from me) of what it could be like, I think what I suggested in comment 23 would be a better idea. But I'll let :mixedpuppy decide.

Comment 28

[Shane Caraveo (:mixedpuppy)]

I personally would not be very supportive of any api that allows an addon to programmatically control primary firefox ui, unless it is simply not possible to manage properly from the web-ext layer.

However, at least initially I think this should be done as an experiment which requires it to be an API.

I suggest "tabManager" permission and namespace for the experiment.  Don't use browser.toolbars, and especially don't add another tabs namespace.

Also this bug seems to be drifting into an all-things-tab-managers needs bug, best to keep this focused, there is a bug for tracking tab-manager related needs.

Comment 29

[mirh]

(In reply to Shane Caraveo (:mixedpuppy) from comment #28)

> Also this bug seems to be drifting into an all-things-tab-managers needs
> bug, best to keep this focused, there is a bug for tracking tab-manager
> related needs.

Which for some strange reason (bug 1333837, right?) hasn't this bug in the dependencies?
Could it be added?

Comment 30

[Timothy Johnson]

I Created an experiment here https://github.com/RedHatter/tabstrip-experiment.

I couldn't figure out how to get the experiment to extend the existing namespace "tabManager". Someone (possibly :mixedpuppy) want to enlighten me?

Comment 31

[kroppy]

To tell you the truth I don't mind if hiding tabstrip would be just an option in Firefox inside "Customize" Under Show/Hide Toolbars. Just like Vivaldi has an option to just hide the tabbar. Of course if you make an API I will be even more happy.

"Also this bug seems to be drifting into an all-things-tab-managers needs bug"
Of course it is, but not only managers, for example "single tab window", would benefit from it as well.

Comment 33

[Caitlin Neiman [:caitmuenster]]

Hi Timothy, we'd love to discuss this experiment at the next WebExtension APIs triage on June 20. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1s2j85VfYKTDftppFU-K7pgRs6sEuMTHVXqf3RL5iYvs/edit#

Comment 34

[Caspy7]

Just wanted to add another data point.

I've read that the Tab Center Testpilot addon will start breaking in 55 and be discontinued in 56.  Currently a Mozilla developer is working on a Webextension-based replacement (Tab Center Redux) which the original will likely point to / refer current users. 

A P1 blocker for it right now is this bug.

Comment 35

[Graham Perrin]

What's all this about sunsetting Tab Center? - Test Pilot / Tab Center - Mozilla Discourse
<https://discourse.mozilla-community.org/t/-/15999>

Comment 36

[8a03524c]

Please forgive me for barging in like this without experience. I created an account just for this. I do have prog/dev experience but am only a simple and faithful user since Netscape 1. Vertical tabs brought me here ("Tree Style Tab"). They've been the best UI feature of FF since they appeared.

Reading this thread, I can't help wonder why not take the opportunity to introduce vertical tabs as an integral part of Firefox, with an option
	"Tabbar position: Top/Bottom/Left/Right/Hidden"

Are the top-level UI objects not free to move without implicating armies of programmers?

Comment 37

[Blake Winton (:bwinton) (:☕️)]

8a03524c: This isn't really the place for that discussion, but as a quick answer, the top-level UI objects are optimized for the position they are in and layout they have, and not enough people want them to be in a different place and format to make it worth the effort developing and maintaining that functionality.

Comment 38

[Andy McKay]

Thanks for the experiment Timothy. I gave this a try in Nightly and noticed a few things right away:
* the window controls were overlaid over the toolbar buttons, so I couldn't click on those toolbar buttons (i've attached a screenshot)
* when I uninstalled the extension, it didn't revert back to normal.

I tried some other events and extensions that manipulated tabs and they seemed to work, so that's awesome.

We spoke about this in the community meeting today and there's a few things that we need to make sure that happen, and its at least:
* an appropriate permission is needed for this to warn the user
* when the extensions that do this are uninstalled, it reverts back to normal
* an event is triggered eg: tabs.onHidden(...) when they are hidden or unhidden

We could file separate bugs for those or keep those on this bug, whichever you'd prefer.

Comment 39

[Andy McKay]

Attachment: Capture.PNG

Comment 40

[sullptcscs]

(In reply to 8a03524c from comment #36)
> Please forgive me for barging in like this without experience. I created an
> account just for this. I do have prog/dev experience but am only a simple
> and faithful user since Netscape 1. Vertical tabs brought me here ("Tree
> Style Tab"). They've been the best UI feature of FF since they appeared.
> 
> Reading this thread, I can't help wonder why not take the opportunity to
> introduce vertical tabs as an integral part of Firefox, with an option
> 	"Tabbar position: Top/Bottom/Left/Right/Hidden"
> 
> Are the top-level UI objects not free to move without implicating armies of
> programmers?

I agree.  I can't understand why this isn't a standard feature.  I can't see how changing the positioning of the tabs is somehow complex when you consider all of the intricacies of browser/software development.

Comment 41

[ojab]

Gently ping, Nightly is updated to have legacy extensions disabled, so this became an actual issue for Nightly users.

Comment 42

[João Lopes]

It's worth noting that, for now, this can be achieved with editing the file chrome/userChrome.css and restarting the browser. It's not ideal but if it is a breaking feature for you personally, it's a reasonable patch.

    #tabbrowser-tabs {
      visibility: collapse !important;
    }

Comment 43

[Caspy7]

There is a discussion on Tab Center Redux's github that that code can be glitchy for some, at least on Mac, and offers this code:

@-moz-document url("chrome://browser/content/browser.xul") {
  #TabsToolbar {
    height: 22px;
  }

  #tabbrowser-tabs {
    visibility: collapse;
  }
}

https://github.com/eoger/tabcenter-redux/issues/15#issuecomment-320735308

Comment 44

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8864009 [details] [diff] [review]
Collapse the tabs bar from manifest.

tweaking toolbars is not on the map for now.

Comment 45

[u462496]

(In reply to Shane Caraveo (:mixedpuppy) from comment #44)
> Comment on attachment 8864009 [details] [diff] [review]
> Collapse the tabs bar from manifest.

Thanks for your work, Shane.

> tweaking toolbars is not on the map for now.

I'm a little confused reading the discussion where this all is ending up.  Does this mean there are no plans for permitting an API to toggle toolbar visibility during a session?

Comment 46

[Edouard Oger [:eoger]]

Attachment: Bug 1332447 part 1 - Pass context to callOnClose() callback.

Review commit: https://reviewboard.mozilla.org/r/170478/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/170478/

Comment 47

[Edouard Oger [:eoger]]

Attachment: Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Review commit: https://reviewboard.mozilla.org/r/170480/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/170480/

Comment 48

[Edouard Oger [:eoger]]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Here is my first stab at this, I apologize if my code has some anti-patterns, I'm not very familiar with this part of the Firefox code.

CSS is used instead of an expensive MutationObserver, from my tests the toolbar stays hidden at all times.
The majority of the code is in an external object (tabVisibilityManager) in order to separate clearly the close() function called by callOnClose().

I'd be happy to start writing tests if the approach here is the right one.

Comment 49

[Edouard Oger [:eoger]]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/170480/diff/1-2/

Comment 50

[Edouard Oger [:eoger]]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Sorry for the spam!

Comment 51

[Andy McKay]

This definitely will need a security review to figure out the permission prompt, since some security things are tied up in the tab. Eg. webRTC.

With the new photon structure and bug 1384515, I wonder how much this is still the way to go.  

How much vertical space in Photon does this save? Does it collapse the window controls down into the URL bar?

Comment 52

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8899202 [details]
Bug 1332447 part 1 - Pass context to callOnClose() callback.

Seems ok, want feedback from Kris.

Comment 53

[Andy McKay]

This definitely will need a security review to figure out the permission prompt, since some security things are tied up in the tab. Eg. webRTC.

With the new photon structure and bug 1384515, I wonder how much this is still the way to go.  

How much vertical space in Photon does this save? Does it collapse the window controls down into the URL bar?

Comment 54

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

https://reviewboard.mozilla.org/r/170480/#review175988

::: browser/components/extensions/ext-tabs.js:88
(Diff revision 2)
> +
> +  set tabsVisible(isVisible) {
> +    this._updateCurrentWindowsTabsVisibility(isVisible);
> +
> +    if (!isVisible) {
> +      tabsVisilityTracker.emit("hidden");

see my comment in onHidden

::: browser/components/extensions/ext-tabs.js:95
(Diff revision 2)
> +      this._hideTabs = (window) => {
> +        // The titlebar height is calculated dynamically, let TabsInTitlebar
> +        // do its job first then collapse the tabstrip.
> +        Services.tm.currentThread.dispatch(() => {
> +          this._updateTabsVisibility(window, false);
> +        }, Ci.nsIThread.DISPATCH_NORMAL);

I think  Promise().then(this._updateTabsVisibility(window, false)); should work

::: browser/components/extensions/ext-tabs.js:376
(Diff revision 2)
>              windowTracker.removeListener("TabPinned", listener);
>              windowTracker.removeListener("TabUnpinned", listener);
>            };
>          }).api(),
>  
> +        onHidden: new EventManager(context, "tabs.onHidden", fire => {

I'm wondering if this should be tabs.onVisibilityChanged and have it called for both hidden and shown, passing "hidden" or "shown" as a value.  This would provide state information for any addon that may want to adjust based on tab strip visibility.

::: browser/components/extensions/ext-tabs.js:383
(Diff revision 2)
> +            fire.async();
> +          };
> +
> +          tabsVisilityTracker.on("hidden", listener);
> +          return () => {
> +            tabTracker.off("hidden", listener);

Seems like this should be tabsVisibilityTracker, not tabTracker.

::: browser/locales/en-US/chrome/browser/browser.properties:116
(Diff revision 2)
>  webextPerms.description.sessions=Access recently closed tabs
>  webextPerms.description.tabs=Access browser tabs
>  webextPerms.description.topSites=Access browsing history
>  webextPerms.description.unlimitedStorage=Store unlimited amount of client-side data
>  webextPerms.description.webNavigation=Access browser activity during navigation
> +webextPerms.description.tabsVisibility=Hide the tabs toolbar

Changes the visibility of the tab strip

::: browser/themes/linux/browser.css:86
(Diff revision 2)
>    z-index: 1;
>  }
>  
> +#TabsToolbar.webext-collapsed > * {
> +  visibility: collapse;
> +}

We'll need feedback from the Firefox team on this.

Comment 55

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Feedback request for the css bits that actually change tab strip visibility.

Comment 56

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

https://reviewboard.mozilla.org/r/170480/#review175990

::: browser/components/extensions/schemas/tabs.json:16
(Diff revision 2)
>          "choices": [{
>            "type": "string",
>            "enum": [
>              "activeTab",
> -            "tabs"
> +            "tabs",
> +            "tabsVisibility"

Also wondering if we can only require the permission to change the visibility, but allow any extension to listen for visibility changes.

Comment 57

[Ralf Jung]

> How much vertical space in Photon does this save? Does it collapse the window controls down into the URL bar?

It's not (just) about saving space.  With a "vertical tabs" extension installed that puts tabs into the sidebar, having two tab bars is redundant and pretty confusing.
(Being on Linux, I didn't even realize window controls are collapsed with the tab bar on other platforms.^^)

Comment 58

[u462496]

(In reply to Andy McKay [:andym] from comment #53)
> With the new photon structure and bug 1384515, I wonder how much this is
> still the way to go.  
> 
> How much vertical space in Photon does this save? Does it collapse the
> window controls down into the URL bar?

Please remember our discussion in bug 1357214, and that this was the (compromise) solution that was offered in favor of closing that bug.  In that case, it also is not about saving space, but being able to provide an alternate UI to satisfy a tab grouping paradigm.

Comment 59

[:Gijs (he/him)]

(In reply to Kevin Jones from comment #58)
> (In reply to Andy McKay [:andym] from comment #53)
> > With the new photon structure and bug 1384515, I wonder how much this is
> > still the way to go.  
> > 
> > How much vertical space in Photon does this save? Does it collapse the
> > window controls down into the URL bar?
> 
> Please remember our discussion in bug 1357214, and that this was the
> (compromise) solution that was offered in favor of closing that bug.  In
> that case, it also is not about saving space, but being able to provide an
> alternate UI to satisfy a tab grouping paradigm.

That decision seems to have been revisited in bug 1384515 without a link from bug 1357214.

Comment 60

[:Gijs (he/him)]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

https://reviewboard.mozilla.org/r/170480/#review176070

In addition to the points below, I think this should get reviewed by Dão for styling implications, and by Jared because he's working on the tab animations and I don't know if/how that stuff would be impacted in that case.

::: browser/components/extensions/ext-tabs.js:81
(Diff revision 2)
> +let tabsVisilityTracker = new EventEmitter();
> +let tabVisibilityManager = {
> +  tabsHiddingContexts: new Set(),
> +
> +  get tabsVisible() {
> +    return this.tabsHiddingContexts.size == 0;

Spelling

::: browser/components/extensions/ext-tabs.js:997
(Diff revision 2)
>              });
>            });
>          },
> +
> +        getTabsVisible() {
> +          return tabVisibilityManager.tabsVisible;

This should probably return the right thing in popup windows?

::: browser/themes/osx/browser.css:180
(Diff revision 2)
>       The animations use position:absolute and require a positioned #nav-bar. */
>    position: relative;
>  }
>  
> +#TabsToolbar.webext-collapsed {
> +  min-height: 27px;

Why, and why only on OS X?

::: browser/themes/windows/browser.css:218
(Diff revision 2)
> +#TabsToolbar.webext-collapsed {
> +  min-height: 31.5px;
> +}
> +
> +#TabsToolbar.webext-collapsed > * {
> +  visibility: collapse;

This won't work with all the selectors we already have for #TabsToolbar[collapsed]. 

I think this code should set the collapsed attribute (and refuse to unhide in popup windows). That would be a lot simpler on the frontend side, though you will need to add logic to do the right thing for popup windows. Note that I think you need to have similar logic anyway to return the right value when an add-on wants to know if the tabstrip is visible in a given window.

Comment 61

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Andy McKay [:andym] from comment #51)
> This definitely will need a security review to figure out the permission
> prompt, since some security things are tied up in the tab. Eg. webRTC.

From reading this bug, it sounds like we need a security design before we can have a security review.
  
Issues like comment 25 aside, to ship this we need to address fundamental risk that we are delegating a portion of the browsers security UI to a 3rd party extension. I don't see how we can make this API completely safe (its dangerous by definition), so we need to make users understand what they are doing when they are installing an add-on with this capability. At a minimum thats something in the install flow (ie permission dialog) but that doesn't seem like enough to me. Some things that we might want to consider: 
- AMO: maybe we have separate category or some clear warnings to tell a user they are installing an addons which overrides UI
- Integration with "customize": maybe we could require add-ons that customise UI to have to be "enabled" somehow through the existing customise UI. (ie explicit opt-in, not just install). This might also provide a way to recover if the addon leaves you in a broken state?
- Maybe we could consider something like "extension configuration options", where a user has to opt-in to granting extensions powerful features (similar to chrome's 'allow extension to access the file system' option)

I can see this being a drawn out UX discussion, and I know we are very stretched so I'm not saying we should necessarily block on any of these suggestions (though we need to have _something_, maybe just the permission dialog for a start). Perhaps we need a separate bug to address 'provide a mechanism for users to opt-in to powerful extension features' bug? Thoughts?

Comment 62

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Andy McKay [:andym] from comment #53)
> This definitely will need a security review to figure out the permission
> prompt, since some security things are tied up in the tab. Eg. webRTC.

Hmm, but we're only talking about hiding the tabs toolbar (not the nav bar), right?

I believe all the permission prompts and current permission status (including WebRTC and others) appear in the nav bar (near the (i) icon in the location bar) today, so I don't understand the security risk of hiding the tabs toolbar.

Or is future Photon / UX work planning to move these security indicators to the tab?

Comment 63

[Jonathan Kingston [:jkt] he/him]

> Or is future Photon / UX work planning to move these security indicators to the tab?

Tab level indicators are used when screen sharing currently. Any recording activities like this is part of the current security model. Screen sharing seems to be the exception here where there isn't an unfocused tab out of window notification so by removing tabs users wouldn't know if something was screen sharing.

Comment 64

[Jonathan Kingston [:jkt] he/him]

Ignore me, it appears to be a bug regarding the icon not shown, either way the security model is to show the user what tab is being shared.

Comment 65

[Edouard Oger [:eoger]]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

https://reviewboard.mozilla.org/r/170480/#review175990

> Also wondering if we can only require the permission to change the visibility, but allow any extension to listen for visibility changes.

I think this is what my patch currently do ;)

Comment 66

[Edouard Oger [:eoger]]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

https://reviewboard.mozilla.org/r/170480/#review176070

> This should probably return the right thing in popup windows?

This "flag" applies to all currently open windows, so I don't think we should make the distinction here.

> Why, and why only on OS X?

There are similar rules for other platforms (see other css files).

> This won't work with all the selectors we already have for #TabsToolbar[collapsed]. 
> 
> I think this code should set the collapsed attribute (and refuse to unhide in popup windows). That would be a lot simpler on the frontend side, though you will need to add logic to do the right thing for popup windows. Note that I think you need to have similar logic anyway to return the right value when an add-on wants to know if the tabstrip is visible in a given window.

For more context about what I'm trying to achieve here, here is what the current patch does:
http://imgur.com/a/9qKL6
 
> I think this code should set the collapsed attribute

This gives me garbage on OSX http://imgur.com/a/9liyz

> when an add-on wants to know if the tabstrip is visible in a given window.

This might be valuable in the future, but for now let's keep the scope to the "global" state. This API is not meant to be called by-window, but for the whole application.

Comment 67

[Edouard Oger [:eoger]]

Comment on attachment 8899202 [details]
Bug 1332447 part 1 - Pass context to callOnClose() callback.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/170478/diff/1-2/

Comment 68

[Edouard Oger [:eoger]]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/170480/diff/2-3/

Comment 70

[:Gijs (he/him)]

(In reply to Edouard Oger [:eoger] from comment #66)
> Comment on attachment 8899203 [details]
> Bug 1332447 part 2 - Implementation of the tabstrip hidding API.
> 
> https://reviewboard.mozilla.org/r/170480/#review176070
> 
> > This should probably return the right thing in popup windows?
> 
> This "flag" applies to all currently open windows, so I don't think we
> should make the distinction here.

So what currently happens in popup windows that don't show the tabstoolbar, showing a titlebar instead, with the current version of the patch, if a webextension hides the tabstrip? Because I expect it won't be right...

> > Why, and why only on OS X?
> 
> There are similar rules for other platforms (see other css files).

On Linux you're only setting visibility:collapse, at least inside the patch... Plus, where does the magic number come from? It's fixed on Windows (different from the OS X number), but no explanation is given... Does it need to be (could it be) different for Win7/Win8/Win10? What about classic/glass on win7?

> > This won't work with all the selectors we already have for #TabsToolbar[collapsed]. 
> > 
> > I think this code should set the collapsed attribute (and refuse to unhide in popup windows). That would be a lot simpler on the frontend side, though you will need to add logic to do the right thing for popup windows. Note that I think you need to have similar logic anyway to return the right value when an add-on wants to know if the tabstrip is visible in a given window.
> 
> For more context about what I'm trying to achieve here, here is what the
> current patch does:
> http://imgur.com/a/9qKL6

I don't think this is what we want. Then the tabstrip/titlebar just becomes useless dead space. Presumably the idea is that the window controls should be on 1 line with the navbar, otherwise why bother hiding anything at all? Either that or, if we don't want to do that, then enforce showing either the native titlebar or its XUL replacement when the tabstrip is hidden (which would be easier to implement as a first step). This would basically make normal windows look like popup windows do now (but with a full complement of UI in the navbar, and potentially the bookmarks toolbar / menubar showing). You could look at how we style (and work within browser-tabsintitlebar.js) those today to work out how to style things the same for the "webextension hid the tabstrip" case.

> > I think this code should set the collapsed attribute
> 
> This gives me garbage on OSX http://imgur.com/a/9liyz

This looks right, except for the garbage bits. browser-tabsintitlebar would probably need updating to show the placeholders in the navbar, and make the right calculations (that bit would be the hard part), and the position:relative stuff will need updating to make the button/icon sizes non-crap (see bug 1383879 for context). Plus we'll need to make sure that the overflowable toolbar stuff runs just like after window resizes, as unhiding the titlebar placeholders reduces the space for customizable items.

Comment 71

[:Gijs (he/him)]

Oh, and on Windows we'd need to make sure that we deal with the user hiding / unhiding the menubar while the tabstrip is hidden, and we hide/show the right placeholders for the window controls, and reposition them accordingly, etc.

On OS X, you'll find that things work slightly differently than on Windows wrt lightweight themes vs. turning the native titlebar on (tabsintitlebar off), so be sure to check that, too.

Comment 72

[Ralf Jung]

> Then the tabstrip/titlebar just becomes useless dead space. Presumably the idea is that the window controls should be on 1 line with the navbar, otherwise why bother hiding anything at all?

Hiding it may still make sense as it avoids having *two* tabbars when using vertical tabs.
But of course, having the window controls in the navbar would be neater.

Comment 73

[devoas]

Being on developer edition I just got upgraded to 57, with all that it implies... Just wanted to point out that hikding tabs for me is a big priority as I do not use them very little, only on some windows, I generally just use windows (at work at least) and they waste space. I'm of the opinion that there are better places to implement tabbing than in applications, namely window manager, but well I know how far I'll get with that... Still I can choose my window manager, and would like to have a chose to not show tab bar, at least when having only a single tab (there was an extension for that of course).

Comment 75

[u592880]

Hey all, FF57 has new shipped in beta version, which means way more people are affected by this. Is there a consensus on how to move forward on this issue?

Comment 76

[Edouard Oger [:eoger]]

Comment on attachment 8899202 [details]
Bug 1332447 part 1 - Pass context to callOnClose() callback.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/170478/diff/2-3/

Comment 77

[Edouard Oger [:eoger]]

Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/170480/diff/3-4/

Comment 78

[Edouard Oger [:eoger]]

Added rules for win7/8/classic theme.

> I don't think this is what we want. Then the tabstrip/titlebar just becomes useless dead space [...]

I tried this on Windows and it looked pretty terrible. This needs a lot of ui/ux design work if we want to pursue your use case of moving the address bar to the tabstrip/titlebar. I would have to say this is beyond the scope of this bug and is probably not what the users of the sidebar tabs want, and would definitely require ui/ux input if we want to think about going in this direction. I don't want to invest any more time in this unless we know this has approval by product design.

I believe there are a lot of people invested in this feature as we can see from any mentions about vertical tabs on reddit/HN that we severely lack the API to simply hide the tabstrip.

I suggest we ship an MVP here, and polish this in the next month before the 58 merge.

Comment 79

[:Gijs (he/him)]

(In reply to Edouard Oger [:eoger] from comment #78)
> Added rules for win7/8/classic theme.
> 
> > I don't think this is what we want. Then the tabstrip/titlebar just becomes useless dead space [...]
> 
> I tried this on Windows and it looked pretty terrible. This needs a lot of
> ui/ux design work if we want to pursue your use case of moving the address
> bar to the tabstrip/titlebar. I would have to say this is beyond the scope
> of this bug and is probably not what the users of the sidebar tabs want, and

I'm not convinced that this is "probably not what [users] want", but even if I was...

> would definitely require ui/ux input if we want to think about going in this
> direction. I don't want to invest any more time in this unless we know this
> has approval by product design.

... you haven't really explained why we can't use the "with titlebar popup" style which we already have, albeit with a minimal navbar instead of a full one, as I also suggested in comment #70 as a first step, given that what I think is the 'best' option is more work. So I still don't understand why we can't just show the actual titlebar instead of a dead bit of space, which I don't think is useful enough to ship. That would also obviate the need for forcing the collapsed tabstrip to have height (and a different value on every OS at that, which, being hardcoded, is probably wrong especially on Windows 10, which does weird dpi-related clamping of titlebar button sizes). So I think that will be (a) simpler than what you have right now, and (b) have fewer bugs because we already test more of it.

Comment 80

[Edouard Oger [:eoger]]

In my opinion, the popup option looks far from ideal on macOS since it doesn't have the vibrancy titlebar. Again, if we really wanted to do something with that empty tabstrip space, I would still suggest consulting with UI/UX before making product decisions on it. 

I was hoping to land a MVP of this feature and continue with my regular work, but I think our visions differs and I don't have the time to work on this any further. I would like to bring product into this discussion and have a final call so someone can prioritize this work and hopefully continue where I have left off. We have a lot of users that deeply care about this feature so I hope we don't disappoint them.

Comment 81

[Jeff Griffiths (:canuckistani) (:⚡︎)]

The discussion here needs to be between UX and Mike, clearing my needinfo

Comment 82

[Markus Jaritz [:designakt] (UX)]

Someone said UX. How can I see the 2 options talked about here?
From what I read, :Gijs proposal sounds simple to implement yet less styled than what :eoger proposes. For a first version, probably both are good. 

What seams most important to me is a design that let's people keep control of their browsers. Meaning they need to know what is happening, why it is happening and how they can revert it. And best, in context of the change. Similar to what we are working on with newTab/home overrides, but probably even more so with all security relevant UI that might not be visible.
Comment #61 already listed some possibility we would need to review to ensure users are aware of what changes and how they can deal with that.
After knowing how this relates to other WebExtension API work (will ask Mike tomorrow), I can work on a proposal of how to transition users to a hidden tabbar.

Comment 83

[:Gijs (he/him)]

(In reply to Markus Jaritz [:designakt] (UX) from comment #82)
> Someone said UX. How can I see the 2 options talked about here?

Running Edouard's patch on my machine looks like this: https://imgur.com/zYkM96v . I think I would prefer something more like this in the short term: https://imgur.com/tl3QNpa . With some design work, I think we should aim to move the caption buttons on one line with the navbar ( a bit like what we do right now if you fullscreen a popup window on 57 on Windows: https://imgur.com/a/BHSdF - but with a full navbar rather than a disabled urlbar, a hamburger button and nothing else. I get that it looks ugly in that screenshot, I think we can make it look good, I just haven't tried here - I have other stuff that needs doing and I'm not a designer).

My understanding is that Edouard thinks that the (default theme) dark (vibrant, on OSX) background is more important, and I would prefer to use the space at the top that's created by removing the tabstrip for something (as a first step by showing the page title, but ideally by putting the window controls on one line with the navbar).

> What seams most important to me is a design that let's people keep control
> of their browsers. Meaning they need to know what is happening, why it is
> happening and how they can revert it. And best, in context of the change.

I agree this is important, but it seems orthogonal to the actual design of the "window without a tabstrip", which seems to be the main reason for disagreement... If an add-on **unexpectedly** removed the tabstrip, it wouldn't matter much if this used Edouard's approach or mine, it would still be surprising without further help to the user...

> Similar to what we are working on with newTab/home overrides,

For those of us not in the loop, can you provide a reference to what you mean here?

> but probably
> even more so with all security relevant UI that might not be visible.
> Comment #61 already listed some possibility we would need to review to
> ensure users are aware of what changes and how they can deal with that.
> After knowing how this relates to other WebExtension API work (will ask Mike
> tomorrow), I can work on a proposal of how to transition users to a hidden
> tabbar.

I believe the concerns here are that we want to:
- implement something quickly / for 57, given the popularity of vertical/treestyle/sidebar tabs
- ensure Firefox looks good (or at least OK) with the tabstrip hidden in all the themes we ship by default as well as lightweight themes, on all the tier-1 OSes
- make sure that collapsing the tabstrip has a benefit in terms of screen real estate being usable for other things
- make sure that the user can't get into an unusable "where are my tabs?!" state without recourse (e.g. when closing the tabs sidebar and not knowing how to get it back, or when in customize mode which doesn't show the sidebar (bug 1394581), or when using an add-on that removes the tabstrip but doesn't provide alternative UI, or when such UI (like a toolbar button) is not on the toolbar)
- make sure tabstrip reimplementations can actually provide the user with the same features the Firefox tabstrip has. Off the top of my head this will mean exposing:
-- titles, urls and favicons, ordering, as well as pinned/unpinned state (and events for when they change - I assume we have all of these)
-- audio state (none, playing, muted, etc., as well as a way of starting playback if we support that from the tabstrip at this point (not sure))
-- screen/webrtc sharing state
-- activity/attention state for modal dialogs and pinned tabs glow
and maybe other things. I don't know how much of that is implemented in webextensions today and how important it is to have all of that implemented before providing this functionality.

Hopefully you and Mike can make a suggestion of how you think we should proceed.

I've tried to present the above as neutral as possible. What follows is personal opinion:
I think we should punt on this for 57. Beta is too far gone, we probably need strings for some of the permissions stuff, and testing is a nightmare. 58 is iffy - it could work if there are folks who can do significant work + testing on this. For 57, I suggest we tell users who really want this:
1) turn on the titlebar (checkbox in customize mode)
2) run with a userChrome.css hack to collapse the tabstrip entirely (and potentially remove the top border on the navbar on OSes where that looks ugly) as suggested in some of the earlier comments.

I think that gets them 90% of the way, and users who use those steps should generally be able to "know what they're doing" in terms of the security/usability implications.

Comment 84

[Caspy7]

(In reply to :Gijs from comment #83)
> (In reply to Markus Jaritz [:designakt] (UX) from comment #82)
> > Similar to what we are working on with newTab/home overrides,

> For those of us not in the loop, can you provide a reference to what you mean here?

I'm thinking this is a reference to bug 1373853 in which if an addon changes your newtab or home page, this will show up in preferences (where you choose your homepage) and the addon can be disabled from there.
Here's a gif illustrating it:
https://twitter.com/FirefoxNightly/status/914822050858008576
====

As a personal aside, a similar angle for this situation is not yet readily apparent to me.

One thought I'd add to the mix is to consider a separate notification *after* the tab bar has been hidden. The user may not have been reading notifications previously, but suddenly the tabs are gone. Say what is responsible with the option to immediately disable it.

Comment 85

[Markus Jaritz [:designakt] (UX)]

(In reply to :Gijs from comment #83)
> For those of us not in the loop, can you provide a reference to what you mean here?

For newTab/Home override, we will show the user a notification, the first time they encounter the change.
https://mozilla.invisionapp.com/share/6HCITJKP8#/244736432_Jazz_-_InContext_-_Home_-_V4_-_01_Override_Confirmation
(If the ignore it, they will see it again after a restart, until they make a decision.)

And to get back to the default, we have a permanent record of the change in about:preference.
https://mozilla.invisionapp.com/share/6HCITJKP8#/242994345_Jazz_-_Preferences_-_General_-_V4_-_04_Override_Home_Page

Caspy7 is spot in with his comment, in both cases. :-)

The permanent place to re-enable default tabs, should probably be more visible. Maybe like the button TabCenter used to switch back to tabs on top. https://github.com/bwinton/TabCenter/issues/691 But with an option to disable the extension causing tabs on top to disappear.

Comment 86

[ojab]

(In reply to :Gijs from comment #83)
> - make sure tabstrip reimplementations can actually provide the user with
> the same features the Firefox tabstrip has. Off the top of my head this will
> mean exposing:
Also private window indicator (i. e. purple mask).

Comment 87

[Andy McKay]

(In reply to :Gijs from comment #83)
> I think we should punt on this for 57. Beta is too far gone, we probably
> need strings for some of the permissions stuff, and testing is a nightmare.
> 58 is iffy

Definitely. Let's get it right, the need to rush something has gone.

Comment 88

[Mike Conca [:mconca]]

At this point, the only things that will make it into 57 are bugs/regressions that would cause a dot release.  This does not rise to that level.

That said, it is a highly requested feature and I'd like to prioritize it fairly high. Gijs does an excellent job of outlining things in Comment 83, but I agree that getting it into 58 is iffy given the UX, implementation, and testing needed. Ideally, we can get this into a WebExtensions experiment in order to try some of these ideas out.

Comment 89

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #88)
> ...
> Ideally, we can get this into a WebExtensions experiment
> in order to try some of these ideas out.

This makes a lot of sense to me. I think vertical tab extensions have often suffered in their own UX because the behaviour of hiding the tabstrip was a 'hack'. If we're to really support and promote this UX pattern it should look and work great, and having a prototype to test is critical.

Comment 90

[Croydon]

Please make sure that it will land at latest in Firefox 59 so that it will be included for sure in the next ESR version. Otherwise it gets even more painful for an ever long time.

Comment 91

[Dietrich Ayala (:dietrich)]

I updated the WebExtension experiment from bug 1384515 to include the experiment from Timothy Johnson up in comment #30:

https://github.com/autonome/webext-experiment-showOnlyTheseTabs

It doesn't have the platform niceties that eoger's patch has, so probably not be super useful for the UX evaluation needed in comments #88 and #89.

However, should be usable for add-devs doing work on tab groups or tree-style tabs type of extensions who want to develop against what that future environment might look like, and give feedback on the API.

Comment 92

[Manish Goregaokar [:manishearth]]

Perhaps as an alternate route we can try to get the bare API in, and ask vertical tab addon authors to not run this by default but expose a pref with the appropriate warning signs? Or make it an about:config pref which tab addon authors can recommend you flip.

AIUI the main problem with releasing the API first and dealing with specifics later is *not* that we may wish to change the API, but it is that currently doing this leads to a loss of functionality wrt tabs (e.g. the sound icon stuff, which extensions cannot reimplement); which users may not be prepared for; and we shouldn't ship APIs that lead to confusing extensions that break things.


I'm willing to port this stuff to an about:config pref if folks think that's an ok option. I think this would satisfy a large chunk of the folks who want this fixed now; asking people to edit userChrome.css is pretty fiddly; about:config is far more "normal" IME.

Comment 93

[:Gijs (he/him)]

(In reply to Manish Goregaokar [:manishearth] from comment #92)
> Perhaps as an alternate route we can try to get the bare API in, and ask
> vertical tab addon authors to not run this by default but expose a pref with
> the appropriate warning signs? Or make it an about:config pref which tab
> addon authors can recommend you flip.

Given the security considerations of "hi, I just made your tabstrip disappear", I think without a clear at-use permission prompt I would want this behind an about:config pref if we do decide to release a rough WIP.

> AIUI the main problem with releasing the API first and dealing with
> specifics later is *not* that we may wish to change the API,

I don't know, actually - it seems there are still some unanswered edgecases as to whether state is add-on-inspectable per-window or not (ie can the add-on tell if the tabstrip is hidden in a window for other reasons, like in a popup window), and/or can be altered per window. I *think* the patch from Edouard implements 1 state across the app, but that wouldn't be sufficient for the "hide the tabstrip in windows with 1 tab" usecase. Maybe we decide(d?) that's not important, but given that it may require API changes to change that later, we best be sure...

> I'm willing to port this stuff to an about:config pref if folks think that's
> an ok option. I think this would satisfy a large chunk of the folks who want
> this fixed now; asking people to edit userChrome.css is pretty fiddly;
> about:config is far more "normal" IME.

IMO, this is clearly not making 57, and we have enough runway for 58 to do something better than an about:config pref. Then again, I'm off on PTO so I can't help much myself right now. :-)

Comment 94

[Ralf Jung]

> the sound icon stuff, which extensions cannot reimplement

They cannot?  Tree Style Tab has a working sound icon. <http://piro.sakura.ne.jp/xul/_treestyletab.html.en>

Comment 95

[u462496]

(In reply to Manish Goregaokar [:manishearth] from comment #92)
> Perhaps as an alternate route we can try to get the bare API in, and ask
> vertical tab addon authors to not run this by default but expose a pref with
> the appropriate warning signs? Or make it an about:config pref which tab
> addon authors can recommend you flip.
> 
> AIUI the main problem with releasing the API first and dealing with
> specifics later is *not* that we may wish to change the API, but it is that
> currently doing this leads to a loss of functionality wrt tabs (e.g. the
> sound icon stuff, which extensions cannot reimplement); which users may not
> be prepared for; and we shouldn't ship APIs that lead to confusing
> extensions that break things.
> 
> 
> I'm willing to port this stuff to an about:config pref if folks think that's
> an ok option. I think this would satisfy a large chunk of the folks who want
> this fixed now; asking people to edit userChrome.css is pretty fiddly;
> about:config is far more "normal" IME.

I agree an about:config pref would be a good WIP option.  Many users of alternate tab UI addons still want the tab strip available anyway.

Comment 96

[Blake Winton (:bwinton) (:☕️)]

For TabCenter, one of the things we noticed was that people wanted (and used) different states for different windows. For windows with lots of tabs, they would put them on the side, but for windows with just a few tabs, they would leave the tabs on top. Manish, would you be willing to make it a per-window API in addition to putting it behind a pref?

Comment 97

[Manish Goregaokar [:manishearth]]

> Manish, would you be willing to make it a per-window API in addition to putting it behind a pref?

I can try? :)

> They cannot?  Tree Style Tab has a working sound icon.

Yeah I was just going off of Gijs' comment which was speculating that they can't. It's good if they can :)

Comment 98

[Manish Goregaokar [:manishearth]]

> Manish, would you be willing to make it a per-window API in addition to putting it behind a pref?


Looking into this, this sounds doable, but I have a couple questions: 

 - Should I be updating the posted patches, or just doing a simpler version (similar to Dietrich's webext experiment) that handles multiple windows
 - Similarly, the posted patches have a tabHidingContexts thing -- is this necessary anymore?
 - Is it possible to make a webext API depend on a pref? Or is it ok if the API is exposed for everyone but it does nothing until the pref is flipped.

Comment 99

[Manish Goregaokar [:manishearth]]

Attachment: Bug 1332447 part 1 - Pass context to callOnClose() callback ;

Review commit: https://reviewboard.mozilla.org/r/188528/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/188528/

Comment 100

[Manish Goregaokar [:manishearth]]

Attachment: Bug 1332447 Part 2 - Implementation of the per-browser tabstrip hiding API;

Review commit: https://reviewboard.mozilla.org/r/188530/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/188530/

Comment 101

[Manish Goregaokar [:manishearth]]

This first-pass makes it per-window. I have yet to figure out:

 - how the event handler should be structured (can we add event listeners to the webext Window object?)
 - if I can make the API depend on a pref

aswan, is there any way I can make a webextensions API depend on a pref?

Comment 102

[Andrew Swan [:aswan]]

(In reply to Manish Goregaokar [:manishearth] from comment #101)
> aswan, is there any way I can make a webextensions API depend on a pref?

There's no way to do this automatically.  I'm assuming that the desired behavior is just that any calls to the API would throw (or return a rejected Promise) with a suitable error message?  It wouldn't be a ton of work to add this to the api schemas, but in the short term, just doing a quick check at the entry point to each api method is probably your best bet.

Comment 103

[Manish Goregaokar [:manishearth]]

Okay, that works too. I was hoping for something more explicit but this is fine. I don't think the actual API will change once we expose it so it's fine to expose it by default I guess.

Thanks.

Comment 104

[Andrew Swan [:aswan]]

(In reply to Manish Goregaokar [:manishearth] from comment #103)
> Okay, that works too. I was hoping for something more explicit but this is
> fine. I don't think the actual API will change once we expose it so it's
> fine to expose it by default I guess.

You were looking for something where the individual API methods would appear and disappear as the pref was flipped?  We do that for optional permissions as they are granted and revoked so we could re-use that capability but it would be a lot more complex than just always having the methods there and having them fail if the pref is off.

It affects how extension authors will have to detect the availability but it doesn't seem like a big difference for them:

```
try {
  await browser.tabstrip.hide();
} catch (e) {
  // notify the user about the pref
}
```

versus

```
if (browser.tabstrip.hide === undefined) {
  // notify the user
} else {
  browser.tabstrip.hide();
}
```

Actually, now that its written down the first one seems more idiomatic to me but we're getting into matters of personal taste...

Comment 105

[Manish Goregaokar [:manishearth]]

Yeah, this does look nicer.

Comment 106

[Manish Goregaokar [:manishearth]]

Attachment: Bug 1332447 Part 3 - Add pref for controlling tab hiding API ;

Review commit: https://reviewboard.mozilla.org/r/188624/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/188624/

Comment 107

[Manish Goregaokar [:manishearth]]

Comment on attachment 8917570 [details]
Bug 1332447 part 1 - Pass context to callOnClose() callback ;

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/188528/diff/1-2/

Comment 108

[Manish Goregaokar [:manishearth]]

Comment on attachment 8917571 [details]
Bug 1332447 Part 2 - Implementation of the per-browser tabstrip hiding API;

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/188530/diff/1-2/

Comment 109

[Manish Goregaokar [:manishearth]]

Need to figure out how to best test this (tips welcome!) but the basic API exists.

It still leaves a (smaller) black bar up top for the window controls; we can refine that as part of the larger plan Gijs discussed. I'm not really sure how to make it smaller or have it switch back to native window controls.

Comment 110

[Zéfling]

Why is it not possible with the context menu to hide/show the tabs bar?

Comment 111

[Dão Gottwald [:dao]]

Comment on attachment 8917571 [details]
Bug 1332447 Part 2 - Implementation of the per-browser tabstrip hiding API;

https://reviewboard.mozilla.org/r/188530/#review193946

::: browser/themes/windows/browser.css:266
(Diff revision 2)
> +#TabsToolbar.webext-collapsed > * {
> +  visibility: collapse;
> +}
> +
> +#TabsToolbar.webext-collapsed {
> +  min-height: 31.5px;

It looks like you really just want visibility: hidden here, rather than visibility: collapse and setting a min-height that's often going to be wrong depending on various factors.

Comment 112

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8917570 [details]
Bug 1332447 part 1 - Pass context to callOnClose() callback ;

I'm really not a WebExtensions peer, so I'm going to redirect this to Shane…

Comment 113

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8917571 [details]
Bug 1332447 Part 2 - Implementation of the per-browser tabstrip hiding API;

I'm really not a WebExtensions peer, so I'm going to redirect this to Shane…

Comment 114

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 8917697 [details]
Bug 1332447 Part 3 - Add pref for controlling tab hiding API ;

I'm really not a WebExtensions peer, so I'm going to redirect this to Shane…

Comment 115

[Manish Goregaokar [:manishearth]]

> It looks like you really just want visibility: hidden here,

This works, but it doesn't fix the black bar issue.

Would there be any way to style it so that the black bar disappears on .e.g fullscreen mac (or regular linux) where the window controls aren't shown anyway?

Comment 116

[Andy McKay]

I have multiple concerns on this API as it is and I'm going to a file a few blocking bugs around security and privacy concerns.

After a quick glance I'm concerned:
* this allows an add-on to change the user interface at run time, we've said no to that in the past (eg: opening sidebars dynamically) because of bad experiences with add-ons.
* this doesn't seem to clean up after itself once its been uninstalled? Perhaps I missed that.

I recommend that we if are going to do this, we do it through a manifest.json entry and at install time enact the changes. When the add-on is uninstalled, we revert the changes (assuming that the user only has one such add-on).

As such we have a theme API and a corresponding manifest entry. Since this is about changing the UI, would it make more sense to be part of the theme API?

Comment 117

[Andy McKay]

Comment on attachment 8917697 [details]
Bug 1332447 Part 3 - Add pref for controlling tab hiding API ;

https://reviewboard.mozilla.org/r/188624/#review194120

::: browser/components/extensions/ext-windows.js:254
(Diff revision 1)
>            let win = windowManager.get(windowId, context);
>            return Promise.resolve(win.tabVisibilityManager.tabsVisibility);
>          },
>  
>          setTabsVisibility(windowId, visible) {
> +          let pref = Services.prefs.getBoolPref("extensions.webextensions.tabHidingApi");

Doing the pref this way does not allow the extension developer to detect if the pref is set or not. If the pref is not set, the API should not be available at all and tabs.setTabsVisibility should fail or not exist.

Although my early notes about tabs.setTabsVisibility being a method developers can call at runtime still apply.

Comment 118

[Andrew Swan [:aswan]]

Comment on attachment 8917697 [details]
Bug 1332447 Part 3 - Add pref for controlling tab hiding API ;

https://reviewboard.mozilla.org/r/188624/#review194120

> Doing the pref this way does not allow the extension developer to detect if the pref is set or not. If the pref is not set, the API should not be available at all and tabs.setTabsVisibility should fail or not exist.
> 
> Although my early notes about tabs.setTabsVisibility being a method developers can call at runtime still apply.

This was discussed in comments earlier in the bug.  It does allows the extension developer to detect the error, they'll catch this error (we could add a property to the Error object so they could distinguish this from other errors without parsing the message string).
Making the API only be present if the pref is set is a pain since we have to inject it and revoke it dynamically when the user changes the pref.

Comment 119

[Geoffrey De Belie (Smile4ever)]

(In reply to Andy McKay [:andym] from comment #116)
> I recommend that we if are going to do this, we do it through a
> manifest.json entry and at install time enact the changes. When the add-on
> is uninstalled, we revert the changes (assuming that the user only has one
> such add-on).

It's not dynamic at all, but for a proof of concept this might work. However, we could add a dialog box (just like optional permissions) that would inform the user before the change to the UI gets applied (and flip a pref if the user approves so the user won't yet annoyed again by the same message?). That way we would have a good and consistent user experience.

> As such we have a theme API and a corresponding manifest entry. Since this
> is about changing the UI, would it make more sense to be part of the theme
> API?

I don't think so. It's not about theming really. We don't change the colors or anything.

Comment 120

[Blake Winton (:bwinton) (:☕️)]

(In reply to Andy McKay [:andym] from comment #116)
> After a quick glance I'm concerned:
> * this allows an add-on to change the user interface at run time, we've said
> no to that in the past (eg: opening sidebars dynamically) because of bad
> experiences with add-ons.
>
> I recommend that we if are going to do this, we do it through a
> manifest.json entry and at install time enact the changes. When the add-on
> is uninstalled, we revert the changes (assuming that the user only has one
> such add-on).

One of the more loved features of Tab Center was the ability to have some windows have tabs on the side, and others (say ones with fewer tabs) have tabs on top. I'm not sure how you would specify that without a runtime method to call…

Comment 121

[Andy McKay]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #120)
> One of the more loved features of Tab Center was the ability to have some
> windows have tabs on the side, and others (say ones with fewer tabs) have
> tabs on top. I'm not sure how you would specify that without a runtime
> method to call…

We could file API as a seperate request and address the questions and concerns it brings in that bug. But at this point I can't ignore that this is breaking some of the principles that we've built up over the last year. Principles I admittedly need to document.

Comment 122

[Steph]

Or the hiding API can just make sure that at any time there will be at least one tab strip, whether vertical or horizontal, so that there can't be any UI dead end where no tab strip is visible.


At some point some of these principles should be relaxed, with a system similar to per-site permissions that can be granted or removed at will.

For instance, one will want uBlock Origin to have access to other add-ons traffic, or Screenshots to get access to about: pages. And indeed, an add-on should be able to move the tab bar on the fly. Relaxed "principles" that affect UI can be moved to a Modify-UI permission...

Comment 123

[devoas]

> Or the hiding API can just make sure that at any time there will be at least one tab strip, whether vertical or horizontal, so that there can't be any UI dead end where no tab strip is visible.

How about no? I know many people take it as given that tabs (at least in browser) is best thing since sliced bread, but I think I wrote somewhere, that not everyone thinks this way (like in certain situation for me, I prefer windows). And there are cases where using windows instead of tabs is preferable, and in those cases having essentially wasted bar is quite bad.

Comment 124

[Simon Sapin (:SimonSapin)]

> * this allows an add-on to change the user interface at run time, we've said no to that in the past (eg: opening sidebars dynamically) because of bad experiences with add-ons.

I agree that this seems like to much power to give an extension. I’d prefer to have the user control whether the tab bar is visible in the "Customize" UI, together with the menu bar and Bookmarks toolbar.


> there are cases where using windows instead of tabs is preferable, and in those cases having essentially wasted bar is quite bad.

Disabling tabbed browsing (effectively limiting to one tab per window) is not the same thing as having multiple tabs but no visible tab bar and no indication that that is the case. If you want UI for the former you should file a separate bug.

(I use Tree Style Tabs and hide the tab bar through userChrome.css. Sometimes when opening a new window the sidebar fails to open automatically and I end up in that situation. It’s quite disorienting, even though I know exactly what’s going on.)

Comment 125

[devoas]

I personally want option to have some windows with tabs, and some without tab bar at all. Like previously there used to be an option - hide tab bar with only one tab. Then it got removed, but there was extension that worked a bit like it, it had keybind to toggle tab bar visibility (again per window). It was a bit inferior to that option, but still functional. Now you can't get rid of tab bar in any way.

Comment 126

[Patrick Dark]

One solution may be to not have an API at all and create a pair of native UI buttons on the toolbar:

1. Show/Hide Top Tabs
2. List Sensitive Tabs

Button 1 toggles the top tab visibility of top tabs on a per window basis, which may also be useful for horizontal tab users wanting to save screen real estate with one click. Control of the top tabs remains 100% within the user's control. When any top tabs are hidden, the button can't be removed from the toolbar.

Button 2 triggers visibility of a clickable drop-down list with all the current and recent tabs involving sensitive (location, microphone, etc) tabs regardless of tab visibility. It should have a number on it listing the number of those tabs active. This should mitigate security issues from having the top tabs hidden. It's paired with Button 1 and likewise can't be removed if any top tabs are hidden.

Vertical tab extension authors can then add their own third button to show/hide their tab bars. This means two clicks to toggle between the horizontal/vertical tab bar orientations (once on Button 1 and again on the extension button), but also means that vertical tab extensions will never know if the top tabs are hidden. (For users that don't want to toggle, they don't ever have to click on anything.)

For convenience, there can be a "vertical_tabs" permission that triggers a *native* prompt asking if the user wants to hide top tabs on extension install and adds the aforementioned buttons to the toolbar if necessary. On uninstall of such an extension, top tabs would revert to the visible state.

Having this button system also means that if the user starts the browser cold with the top tabs hidden and somehow the vertical tab extension fails, there's an obvious way to get the horizontal tabs back.

Comment 127

[sullptcscs]

(In reply to Patrick Dark from comment #126)
> One solution may be to not have an API at all and create a pair of native UI
> buttons on the toolbar:
> 
> 1. Show/Hide Top Tabs
> 2. List Sensitive Tabs
> 
> Button 1 toggles the top tab visibility of top tabs on a per window basis,
> which may also be useful for horizontal tab users wanting to save screen
> real estate with one click. Control of the top tabs remains 100% within the
> user's control. When any top tabs are hidden, the button can't be removed
> from the toolbar.
>I like it.  The buttons make sense for ease of use and a simple way to restore things.

 
> Button 2 triggers visibility of a clickable drop-down list with all the
> current and recent tabs involving sensitive (location, microphone, etc) tabs
> regardless of tab visibility. It should have a number on it listing the
> number of those tabs active. This should mitigate security issues from
> having the top tabs hidden. It's paired with Button 1 and likewise can't be
> removed if any top tabs are hidden.
> 
> Vertical tab extension authors can then add their own third button to
> show/hide their tab bars. This means two clicks to toggle between the
> horizontal/vertical tab bar orientations (once on Button 1 and again on the
> extension button), but also means that vertical tab extensions will never
> know if the top tabs are hidden. (For users that don't want to toggle, they
> don't ever have to click on anything.)
> 
> For convenience, there can be a "vertical_tabs" permission that triggers a
> *native* prompt asking if the user wants to hide top tabs on extension
> install and adds the aforementioned buttons to the toolbar if necessary. On
> uninstall of such an extension, top tabs would revert to the visible state.
> 
> Having this button system also means that if the user starts the browser
> cold with the top tabs hidden and somehow the vertical tab extension fails,
> there's an obvious way to get the horizontal tabs back.

Comment 128

[kroppy]

(In reply to Simon Sapin (:SimonSapin) from comment #124)

> I agree that this seems like to much power to give an extension. I’d prefer
> to have the user control whether the tab bar is visible in the "Customize"
> UI, together with the menu bar and Bookmarks toolbar.

I agree 100% here. Just like Vivaldi has preferences for tabs in their settings.
I already said that before in comment 31.
Option to revert back is really important if some "tab manager" extension has some bug and you can't access tabs, unless/until you disable the extension.

Comment 129

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8917571 [details]
Bug 1332447 Part 2 - Implementation of the per-browser tabstrip hiding API;

https://reviewboard.mozilla.org/r/188530/#review195092

I'm giving feedback, not a review, until I'm clear we're accepting this in general.

::: browser/components/extensions/ext-browser.js:731
(Diff revision 2)
>  
> +
> +class TabVisibilityManager {
> +  constructor(win) {
> +    this.window = win;
> +    this.tabHidingContexts = new Set();

Use a weakset to hold the contexts.

::: browser/components/extensions/ext-browser.js:749
(Diff revision 2)
> +  _updateTabsVisibility(isVisible) {
> +    let toolbar = this.window.window.document.getElementById("TabsToolbar");
> +    if (isVisible) {
> +      toolbar.classList.remove("webext-collapsed");
> +    } else {
> +      toolbar.classList.add("webext-collapsed");

why not just use visibility: hidden as dao suggested, but directly rather than via a webext-collapsed class?

::: browser/components/extensions/ext-browser.js:787
(Diff revision 2)
> +};
> +
>  class Window extends WindowBase {
> +  constructor(extension, window, id) {
> +    super(extension, window, id);
> +    this.tabVisibilityManager = new TabVisibilityManager(this);

You're adding a circular reference here, I'd rather not see that.  I wonder if this shouldn't just be a part of the window class itself.

::: browser/components/extensions/ext-windows.js:244
(Diff revision 2)
>              };
>              windowTracker.addListener("domwindowclosed", listener);
>            });
>          },
> +
> +        getTabsVisibility(windowId) {

per my comment on the schema, I'd lean towards this being a window attribute [boolean Window.tabVisibility].  All it needs to do is check for the visibility style.

::: browser/components/extensions/schemas/windows.json:458
(Diff revision 2)
>              "parameters": []
>            }
>          ]
> +      },
> +      {
> +        "name": "getTabsVisibility",

rethinking a touch here, I think that tabVisibility should just be an attribute on the Window object rather than a function call.

::: browser/components/extensions/schemas/windows.json:460
(Diff revision 2)
>          ]
> +      },
> +      {
> +        "name": "getTabsVisibility",
> +        "type": "function",
> +        "async": "callback",

no callback in new APIs, async: true

Comment 130

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8917697 [details]
Bug 1332447 Part 3 - Add pref for controlling tab hiding API ;

https://reviewboard.mozilla.org/r/188624/#review195080

::: browser/components/extensions/ext-windows.js:88
(Diff revision 1)
>            let windows = Array.from(windowManager.getAll(), win => win.convert(getInfo));
>  
>            return Promise.resolve(windows);
>          },
>  
>          create: function(createData) {

We should probably have an option to hide the tabstrip immediately rather than creating the window then having to call the visibility setter.

::: browser/components/extensions/ext-windows.js:248
(Diff revision 1)
>  
>          getTabsVisibility(windowId) {
> +          let pref = Services.prefs.getBoolPref("extensions.webextensions.tabHidingApi");
> +          if (!pref) {
> +            throw new ExtensionError("Tab hiding API is disabled");
> +          }

IMO we don't need to check the pref when getting the value, only for setting.  And per my feedback in the other patch, this should probably just be an attribute on the window.

Comment 131

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(Removing need info as I've provided security input elsewhere)

Comment 132

[Kris Maglione [:kmag]]

Comment on attachment 8917571 [details]
Bug 1332447 Part 2 - Implementation of the per-browser tabstrip hiding API;

https://reviewboard.mozilla.org/r/188530/#review195092

> You're adding a circular reference here, I'd rather not see that.  I wonder if this shouldn't just be a part of the window class itself.

Cyclic references aren't a problem in JS. If you find any cases (that don't involve non-cycle-collected native types) where they do cause problems, please file a bug.

Comment 133

[sullptcscs]

Just a thought from a non-programmer...what if all colors here were set to the same (see link)...essentially making the tab text, close button, tab background/outline the same.  Though it is not 'hiding' the tab bar it would make it less distracting if a user was using vertical sidebar tabs.  If the sidebar tabs were open the color settings of the regular tabs would become the same & if closed return to default.  https://twitter.com/johnmgruen/status/919752791597486081

I'm just thinking of unconventional ways to approach this and thought I would post.  Thanks for all of your work on this.

Comment 134

[Tim Nguyen :ntim]

(In reply to sullptcscs from comment #133)
> Just a thought from a non-programmer...what if all colors here were set to
> the same (see link)...essentially making the tab text, close button, tab
> background/outline the same.  Though it is not 'hiding' the tab bar it would
> make it less distracting if a user was using vertical sidebar tabs.  If the
> sidebar tabs were open the color settings of the regular tabs would become
> the same & if closed return to default. 
> https://twitter.com/johnmgruen/status/919752791597486081
> 
> I'm just thinking of unconventional ways to approach this and thought I
> would post.  Thanks for all of your work on this.

It could be, however you would still see the tab icon and loading indicators.

Comment 135

[sullptcscs]

I see...so could an additional setting be done to eliminate the tab icon &/or loading indicators?  I imagine that might involve a different API from the 'theme API' John demonstrated.

Comment 136

[tumpio]

In long run, this "API" should target all toolbars, not just the Tabs toolbar. For that there is a bug 1215064 that has the goal of designing and implementing an API for browser toolbars.

Comment 137

[polkovnikov.ph]

Could you please make a short update on status of this issue? New GUI have already landed in production, and the best available options are less than satisfactory (https://news.ycombinator.com/item?id=15342379).

Vertical tab extensions have updated to WebExt in a non-compatible way, dropped support for old versions of Firefox, including current ESR. Firefox Add-ons page doesn't allow to get old versions of add-ons either. This issue is a bit more serious than it seems, even though it concerns a small part of users.

Comment 138

[Mastacheata]

(In reply to polkovnikov.ph from comment #137)
> Firefox Add-ons page doesn't allow to get old versions of add-ons either.

That must be a problem specific to one addon that doesn't have any old versions.
But for all Addons with more than one version you should be able to pick up old versions from the "More Information" Panel on the left side. There's a section labeled Version History and a link "See all versions".
You can also just append /versions/ to the URL of the Addon page you're looking at. (Example: https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/versions/)

Comment 139

[polkovnikov.ph]

(In reply to Mastacheata from comment #138)

> But for all Addons with more than one version you should be able to pick up
> old versions from the "More Information" Panel on the left side.

Oh, thanks! That link is really hidden. Probably I should also find/create a feature request to put the latest compatible version of add-on on "Add to Firefox" button.

Comment 140

[nemo]

So. https://hacks.mozilla.org/2017/12/webextension-tree-style-tab/ is currently trending on front page of Hacker News.  I perked up because this extension might possibly somewhat mitigate the loss of Tab Panorama (I'm still not looking forward to the job of recreating all those tab groups ☹ )

Anyway. He links to this bug, and notes that userChrome.css is the only workaround right now to hide the tab bar.
mkaply thoughtfully noted that loading: chrome://browser/content/browser.xul  allows the builtin inspector to find what I was looking for.

If anyone comes by here from the tree style tab page,   it looks like #TabsToolbar { display: none !important }  in chrome/userChrome.css under your profile should do the trick.

Comment 141

[nemo]

You know what... Nevermind.  These CSS rules showed up in the HN comments and are more elegant.
https://news.ycombinator.com/item?id=15870663 

Anyone dropping by should use those as a workaround IMO.

The loading chrome into url to inspect it is still handy tho ☺  - more convenient than https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Comment 142

[Kyra]

Is this still being worked on?

Comment 143

[Mastacheata]

(In reply to kxra from comment #142)
> Is this still being worked on?

It looks like this bug stalled and someone picked up on it in Bug 1384515
I guess that one obsoletes/supercedes this bug, but they don't even reference any common parent/related bugs.

Comment 144

[Edouard Oger [:eoger]]

No, bug 1384515 is about hiding individual tabs.

Comment 145

[Mastacheata]

(In reply to Edouard Oger [:eoger] from comment #144)
> No, bug 1384515 is about hiding individual tabs.

Ahh, you're right, sorry. 
Must have mixed up things and didn't even notice the title explicitly stating this was about hiding the tabstrip.

Comment 146

[Mastacheata]

(In reply to Mastacheata from comment #145)
> (In reply to Edouard Oger [:eoger] from comment #144)
> > No, bug 1384515 is about hiding individual tabs.
> 
> Ahh, you're right, sorry. 
> Must have mixed up things and didn't even notice the title explicitly
> stating this was about hiding the tabstrip.

Though, on a closer look, at least the experiment by :dietrich which was then expanded on by :mixedpuppy into an epxerimental built-in feature had an API for hiding the tabstrip as well. (See: https://bugzilla.mozilla.org/show_bug.cgi?id=1384515#c65 and https://github.com/autonome/webext-experiment-showOnlyTheseTabs/blob/f6253cfd5a65c592dd47077044564b72c3110a09/experiment/api.js#L104)

Comment 147

[Markus Jaritz [:designakt] (UX)]

(In reply to Mastacheata from comment #143)
> (In reply to kxra from comment #142)
> > Is this still being worked on?
> 
> It looks like this bug stalled and someone picked up on it in Bug 1384515
> I guess that one obsoletes/supercedes this bug, but they don't even
> reference any common parent/related bugs.

I am currently working on the UI needed for hiding individual tabs. I talked about the current state of this in last weeks Add-on Demo time: https://air.mozilla.org/add-ons-demos-meeting-20180126/

Once that is done, I will look into hiding the full tabstrip. (Assuming we will need similar UI for that.)
Based on the work other people did on hiding the tabstrip, I picture this to look something like this: (heavily WIP!)
https://mozilla.invisionapp.com/share/KXEUSPHHN#/266445455_Project_Jazz_-_Tab_Hiding_-_ALL_Tabs_Hidden_-_Notice_Opt1_Copy

Comment 148

[melchior blausand]

(In reply to 8a03524c from comment #36)
> (…) Vertical tabs (…) [have] been the best UI feature of FF since they appeared.
> 
> Reading this thread, I can't help wonder why not take the opportunity to
> introduce vertical tabs as an integral part of Firefox, with an option
> 	"Tabbar position: Top/Bottom/Left/Right/Hidden"
> 
> Are the top-level UI objects not free to move (…)?

Judging from allover reception in the former vertical tabs' add-ons category and from user feedback, this should for sure have been a native UI feature of the Photon era. Of course, most people couldn't articulate their appreciation before someone took them by their mouse and introduced the three blessings of vertical tabs: Tree sorting, screen estate optimisation, title display in a 16:9 world.
For this reason, i dare to contradict :bwinton when he replies:

(In reply to Blake Winton (:bwinton) (:☕️) from comment #37)
> 8a03524c: (…) not enough people want them to be in a different place and format to make it worth the effort developing and maintaining that functionality.

Ok, so now i spent over 2 hours to keep myself updated about this discussion. Meanwhile it's March 2018 and we've been foxing on with two tab containers for half a year. While :andym agrees that… 

(In reply to Andy McKay [:andym] from comment #87)
> Definitely. Let's get it right, the need to rush something has gone.

PS.: Thanks for linking this bug to any ongoing discussions regarding native vertical tabs.

Comment 149

[Hlsg]

(In reply to melchior blausand from comment #148)
> Of course, most people couldn't articulate their
> appreciation before someone took them by their mouse and introduced the
> three blessings of vertical tabs: Tree sorting, screen estate optimisation,
> title display in a 16:9 world.

That's only one side of the story. You wouldn't believe how vocal ex. Tab Mix Plus users are on a proper multi-row tab-bar(right now we're doing it via userchrome.css and it's hacky, just like Tree Style Tab is hiding the native tab-bar AFAIK. Fortunately, both hiding the tab-bar and an API are a goal, so we'll get there. I disagree that these should be native, though. Mozilla devs can't please everybody's tastes, so this is best left to webextensions.

Comment 150

[Mike Conca [:mconca]]

https://wiki.mozilla.org/Bug_Triage/Process/Triage

This feature is not actively being worked, but is part of the planned Firefox backlog. Per the Bugzilla triage guidelines linked above, it is being moved to P3.

Comment 151

[Tradewatcher]

Where is the problem to make an extra entry in the menu bar > View > Sidebars > Hide Tab bar??? is this so complex?

Comment 152

[sullptcscs]

Ditto...literally the simplest thing to implement made to seem like the hardest by Mozilla IMHO. Literally just follow what Vivaldi has in place. I appreciate all the work by devs here and blame FF for this degree of complexity.

Comment 153

[Tim Nguyen :ntim]

Some stuff the API should take in account:

- some UI buttons are in the tab bar, which means the tab bar should be un-hidden in the customization mode, so users can drag them out from the tab bar
- the browserAction API allows specifying a `default_area` which can be the tabstrip, if the tabstrip is hidden, this should instead default to the navigation bar.

Comment 154

[qwertyuiopyozo]

Is there a reason we don't just give extensions access to a customizations API and then create toolbar hiding prefs in customize, similar to those that already exist for title bar, menu bar and bookmarks toolbar.
This would also allow users to hide the tab bar without an extension.

Comment 155

[Graham Perrin]

Catching up on a few months' worth of things …

----

(In reply to qwertyuiopyozo from comment #154)

> … give extensions access to a customizations API …

Maybe of interest: 

<https://bugzilla.mozilla.org/showdependencytree.cgi?id=1215059&hide_resolved=1>

– the dependency tree for bug 1215059 - (webextensions-additional-apis) [meta] Extend WebExtensions with custom APIs so more legacy add-ons can be ported

----

More generally: 

- might Firefox Test Pilot gain a second 'vertical tabs' experiment? 

A successor to the Tab Center experiment, <https://testpilot.firefox.com/experiments/tab-center>. Test Pilot could (again) be an ideal way for interested end users, and developers, to help determine the shape of things. This time, with the API for 1332447 as part of a bigger picture.

Comment 156

[Petri Sirkkala]

How about hiding the tabbar but adding a pulldown menu containing all the tabs and warnings before the location bar. Preferably the pulldown could also be toggled to stay open. :)

Comment 157

[Graham Perrin]

With an API for toolbars (bug 1215064) on the roadmap <https://wiki.mozilla.org/Firefox/Roadmap#Personal> for 2018, IIUC: 

- please, what's the possibility of an API to hide the tabstrip also landing, or preparing to land, in 2018? 

Or 2019?

I guess the answer is "as long as a piece of string" :-) whilst this bug is unassigned. Just curious … TIA

Comment 158

[damien.d]

Today's screens are rectangular and we lose much reading height because of it. Not speaking of those fixed banners on many websites.

Hiding horizontal tabs is a highly expected feature.

Comment 159

[Tim Nguyen :ntim]

Might have become a bit easier with bug 1356920 fixed.

Comment 160

[auralarchitect]

(In reply to melchior blausand from comment #148)
> (In reply to 8a03524c from comment #36)
> > (…) Vertical tabs (…) [have] been the best UI feature of FF since they appeared.
> > 
> > Reading this thread, I can't help wonder why not take the opportunity to
> > introduce vertical tabs as an integral part of Firefox, with an option
> > 	"Tabbar position: Top/Bottom/Left/Right/Hidden"
> > 
> > Are the top-level UI objects not free to move (…)?
> 
> Judging from allover reception in the former vertical tabs' add-ons category
> and from user feedback, this should for sure have been a native UI feature
> of the Photon era. Of course, most people couldn't articulate their
> appreciation before someone took them by their mouse and introduced the
> three blessings of vertical tabs: Tree sorting, screen estate optimisation,
> title display in a 16:9 world.
> For this reason, i dare to contradict :bwinton when he replies:
> 
> (In reply to Blake Winton (:bwinton) (:☕️) from comment #37)
> > 8a03524c: (…) not enough people want them to be in a different place and format to make it worth the effort developing and maintaining that functionality.
> 
> Ok, so now i spent over 2 hours to keep myself updated about this
> discussion. Meanwhile it's March 2018 and we've been foxing on with two tab
> containers for half a year. While :andym agrees that… 
> 
> (In reply to Andy McKay [:andym] from comment #87)
> > Definitely. Let's get it right, the need to rush something has gone.
> 
> PS.: Thanks for linking this bug to any ongoing discussions regarding native
> vertical tabs.

I am in full agreement about support for vertical tabs and its inherent benefits.
Essentially there is quite a discrepancy between web pages (in general) and the desktop hardware with which we access & view them.  Web pages are thin and tall while display screens are wide and short- this is particularly acute on many (slightly older or lower cost-range) laptops.  It becomes very desirable to use the vertical real-estate as stingily as possible!
I'm constantly seeking to maximize my vertical viewing space as much as possible.
The fact that I can't disable the tab bar, which I already have displayed on the side is very frustrating and silly!
I admit I don't understand all the technical issues, and I agree that the location should not be hidden, certainly not as part of this bug!  It just doesn't seem logical that hiding the tab bar could really be so complicated.

I find it quite disturbing and discouraging that not only has this not been fixed, but that it hasn't even been assigned to anyone!
I wish there was something that I was capable of doing to expedite this process, but my skill set limits me.

Please do not misconstrue my aggravation for criticism or for a lack of gratitude or respect!  I mainly just want to add another voice in support of this...

Thank you!

Comment 161

[Botond Ballo [:botond]]

(In reply to auralarchitect from comment #160)
> I find it quite disturbing and discouraging that not only has this not been
> fixed, but that it hasn't even been assigned to anyone!
> I wish there was something that I was capable of doing to expedite this
> process, but my skill set limits me.

I think one of the reasons this hasn't been getting much priority, is that users of extensions like Tree Style Tab (of which I am one) have been finding the workaround of hiding the tab bar using userChrome.css [1] to be good enough.

[1] https://github.com/piroor/treestyletab/wiki/Code-snippets-for-custom-style-rules#hide-horizontal-tabs-at-the-top-of-the-window-1349

Comment 162

[Keith Hizal]

(In reply to Botond Ballo [:botond] from comment #161)
> (In reply to auralarchitect from comment #160)
> > I find it quite disturbing and discouraging that not only has this not been
> > fixed, but that it hasn't even been assigned to anyone!
> > I wish there was something that I was capable of doing to expedite this
> > process, but my skill set limits me.
> 
> I think one of the reasons this hasn't been getting much priority, is that
> users of extensions like Tree Style Tab (of which I am one) have been
> finding the workaround of hiding the tab bar using userChrome.css [1] to be
> good enough.
> 
> [1]
> https://github.com/piroor/treestyletab/wiki/Code-snippets-for-custom-style-
> rules#hide-horizontal-tabs-at-the-top-of-the-window-1349

The problem with userChrome.css is that it's techically unsupported in Quantum, which means that it theoretically could break at any time, which for an end user would mean an unusable browser until they figured out what was wrong and manually debugged it.

Comment 163

[mj_jernigan]

It seems to me that if the engineering of the browser doesn't allow for this request to ever happen, then perhaps this request should be closed and the conversation directed towards the use cases behind the request and how to best address those.

If, for example, the primary use case is to implement vertical tabs instead of horizontal tabs, then perhaps FF should provide a built-in option for which edge to locate the tabs on.  Nothing about that should break the core engineering because the tabs are still always present.  And, maybe that satisfies 60% of the use cases, which takes a lot of heat off this.

Then, once that's done.  Maybe take a look at built-in support for multiline tabs.  (I forget: Does FF have that already?  I abandoned FF for Waterfox as soon as I couldn't hide the tab bar any longer so, sorry, I don't know the current status of multiline tabs -- but some comments here seemed to indicate they aren't available.)

Then, once that's done.  Take a deeper look at specific details for what more might be needed in terms of API for stylizing the tabs and tab bar for those who want even more out of it, such as tree tabs.  Set tab width, tab height, order, extra icons, whatever is doable.  Enforce minimums, if needed, to avoid opening loopholes to hide a tab or the bar completely, since it sounds like such things would be bad.  Then, see where the creativity of the developers take it and continue to adapt to the use cases as needed and forget this whole discussion.  So, maybe a tree tab bar could no longer collapse tabs completely, but maybe collapsing down to a couple pixels is good enough.

Now, I expect this comment will get hidden for some loose reason but, seriously, solve use cases instead of getting hung up on whether or not tool X should be able to do Y (when Z might get you to the same destination).  Do it different.

Comment 164

[Dão Gottwald [:dao]]

(In reply to Petri Sirkkala from comment #156)
> How about hiding the tabbar but adding a pulldown menu containing all the
> tabs and warnings before the location bar. Preferably the pulldown could
> also be toggled to stay open. :)

We already have such a menu at the end of the tab bar when it overflows. It should be possible to move or duplicate that button into the nav bar.

(In reply to Tim Nguyen :ntim (please use needinfo?) from comment #159)
> Might have become a bit easier with bug 1356920 fixed.

Indeed.

Comment 165

[mb]

Poke to anyone of authority. What's the progress on this? Hiding the tab strip via userChrome is a workaround but it'd be nice to have an official implementation.

Comment 166

[nuno_m_resende]

Navbar Oneliner w/ userChrome.js

Entire imgur.com post with description

As XBL has been removed and XUL removal in the horizon and userChrome.css being considered legacy and userChrome.js future support unknown, i am leaving my (design) suggestion of what i consider a ergonomic, present way of having a minimal toolbar (for vertical tab addons) that does not compromise security or tab visibility, in the hope it will be implemented with HTML Custom Elements or considered in the design of the (nav)bar whether (or not) tabstrip hide API lands.

Comment 167

[jljatone]

any update from FF devs here? tabs are my major pain point with browsers. I use a tiling window manager, which makes firefox a pain due to it internally handling the windows which crimps my workflow.

and most of the issues brought up in this issue seem to be solvable: move tab indicators to navbar, add option in prefs/about:config to hide tabstrip.

I suspect ignoring the API entirely would be acceptable to the vast majority of the minority users (like myself).

those users are already going miles beyond that by manually modifying chrome.css

a manual step in preferences/about:config to hide the tabstrip would be a infinitely better situation than the status quo.

Comment 168

[Sagar]

Would love to get a recent update on this as vertical tab extensions are on the rise with the increased WFH happening on resultant smaller (and wider) screens

Comment 170

[erik.itland]

I'd suggest this issue is reclassified as a bug as this is a feature that used to be available just fine on previous versions of Firefox.

Furthermore I suggest taking a step back and thinking about why this is so hard:

• Compared to for example Vivaldi, Mozilla is a giant - and they manage to let users move the tab bar around.
• Movable tool bars have been possible since Office I-don't-know-when

Is there a possibility that someone is overcomplicating this?

Furthermore: for now there exist hack to remove the top tab bar but they are hard and there's also reason to believe they won't be available forever.

Comment 171

[:Gijs (he/him)]

(In reply to erik.itland from comment #170)

• Movable tool bars have been possible since Office I-don't-know-when

The toolbars there don't depend on each other in terms of styling, and they don't have tabs-in-titlebar styling to deal with for all the other toolbars.

Is there a possibility that someone is overcomplicating this?

Questioning people's motives is not OK, please see the etiquette and participation guidelines.

Comment 172

[erik.itland]

Questioning people's motives is not OK

Most important first: I'm not questioning developers motives. Only asking if a simpler solution has been overlooked.

The toolbars there don't depend on each other in terms of styling, and they don't have tabs-in-titlebar styling to deal with for all the other toolbars.

I'm fairly certain toolbars used to be styleable at least in some versions of Office.

Still: Vivaldi lets you move tab bars around.

Also more importantly perhaps: styling of Tree Style Tabs-type extensions will be done by developers of such extensions.

Comment 173

[Marius Piedallu van Wyk]

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

Questioning people's motives is not OK, please see the etiquette and participation guidelines.

I just wished this was addressed after the very first post:

A common use case, with lots of rabid users is a vertical tab solution.

Seems the tone for this topic was set long ago and not addressed.

Comment 174

[:Gijs (he/him)]

(In reply to Marius Piedallu van Wyk from comment #173)

A common use case, with lots of rabid users is a vertical tab solution.

Seems the tone for this topic was set long ago and not addressed.

I agree that that's not great either.

At this point, more comments here aren't helping. The problem is well-understood, it is not trivial to fix in a way that we can comfortably ship to all of Firefox's users (not just the expert ones using TST or other similar add-ons and comfortable changing userChrome.css), we know lots of people want us to fix it -- but nobody is currently working on it, because other work is taking priority. That may change in the future, but more comments do not help make that happen or make anything go faster, and lots of people commenting also won't make us change priorities - they will just e-mail the 200+ people CC'd here, most of whom are just other people also interested in this bug.

Comment 175

[jljatone]

that may change in the future, but more comments do not help make that happen or make anything go faster, and lots of people commenting also won't make us change priorities

its extremely unlikely this will be prioritized if it hasn't been any movement on the issue by now. from an outside developers point of view, which may be inaccurate since I'm not present for internal conversations obviously, there doesn't seem to be anyone with a will to make a plan for this feature to be implemented and without a plan no meaningful progress will ever be made towards an implementation.

I'd bet there are some developers out there willing to work on it because they want the feature (I know this is true because I am one of them).
However, without clear requirements on what is required by mozilla to attempt such a thing its not really worth pursuing the work.

off the top of my head information that would be needed to attempt an implementation for oneself.

1. is mozilla even willing to consider a patch from an outside contributor for the feature?
2. who are the various stakeholders involved? based on this report I see security is involved, design is involved, the api team is involved.
3. given the list of stakeholders how does one get buy in? anyone willing to work on the feature will need to discuss with multiple people to figure out any constraints.
4. what are the actual dimensions of the issue, I see the following desires from various users: vertical tabs, webapi for completely custom tabs, a way to disable tabs entirely (this is my personal preference, as using firefox inside my tiling window manager is burdensome).

from the issue's history it seems like even the basic information required to move forward is unknown. if there is no plan for how to accomplish this feature then it'll never be prioritized, and if there isn't anyone willing to come up with the plan then there will it will simply never happen.

if mozilla can articulate a plan for what steps it would like to see in order to move forward with implementing such a feature, then maybe progress can be made. but as it stands right now, its seems that no progress will be made at all for many more years which is unfortunate.

Comment 176

[erik.itland]

To add to what jljatone says:

I think a good number of us would even be happy to chip in to pay a developer or two to create a fix for this if we knew that it would have a fair chance of getting accepted.

Personally I'd be happy to donate USD 50 right away (and more later in the month if that is what it takes). I'd also chip in for other api improvements as well because for me Firefox is a tool and it is insanely frustrating to live with the current limitations given that I know how well it use to work.

(For the record: I know about the userstyles hack, but that keeps getting more and more hidden. Now I think one has to enable a setting to re-enable something deprecated to load the style sheet.)

Comment 177

[erik.itland]

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

[...]we know lots of people want us to fix it -- but nobody is currently working on it, because other work is taking priority. That may change in the future, but more comments do not help make that happen or make anything go faster,

Can you tell me then, what will work? How do I get Mozillas attention?

[...] they will just e-mail the 200+ people CC'd here, most of whom are just other people also interested in this bug.

I guess most of them are actually happy someone is pushing Mozilla on this one, at least I am when someone keeps carefully pushing an issue I subscribe to.

Comment 178

[Martin Häcker]

Sadly there is no way to second what @erik.itland said, without generating another post. Otherwise I would have just added a 🎉.

Comment 179

[:Gijs (he/him)]

(In reply to erik.itland from comment #177)

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

[...]we know lots of people want us to fix it -- but nobody is currently working on it, because other work is taking priority. That may change in the future, but more comments do not help make that happen or make anything go faster,

Can you tell me then, what will work? How do I get Mozillas attention?

As I tried to explain before, the problem isn't one of "attention". There is no "if only I talk to the right person about how important this is to me, they will do it". We've done the calculus and at least right now, planning and doing the work here is high enough cost and small enough value that it isn't as important as the work we are doing, so we are not doing it. I understand that this isn't what you want to hear, because the cost/value proposition is clearly different to you than it is to Mozilla, but just repeatedly telling people that (or telling different people at Mozilla that) isn't going to change it.

Comment 180

[u592880]

Unfortunate to see that, despite requests for almost 20 years, this is still not addressed. I see the points made above about the high cost/low reward, but still.

Comment 181

[Marius Piedallu van Wyk]

They are letting the browser market share decide this... if enough people move away because they cannot find this feature, then the feature becomes important enough.

This makes sense actually.

Sadly I have found very nice vertical tabs in the latest Edge Chromium, which currently for me is beating both Chrome and Firefox in many other areas as well. So using this for my work laptop with limited vertical resolution.

Comment 182

[BlueRaja.admin]

Maybe this bugtracker needs a way to vote on issues? Because this is probably one of the most highly desired features in the entire app, so "low reward" is just plain false.

Comment 183

[John Veness]

(In reply to BlueRaja.admin from comment #182)

Maybe this bugtracker needs a way to vote on issues?

Hi, it does. Expand the Details section at the top.

Comment 184

[polkovnikov.ph]

Sadly I have found very nice vertical tabs in the latest Edge Chromium, which currently for me is beating both Chrome and Firefox in many other areas as well. So using this for my work laptop with limited vertical resolution.

Thank you so much, Marius. I never expected to switch to Edge, but it actually has vertical tabs, and they work properly, unlike constantly crashing TreeStyleTab on recent versions of Firefox. Given that Edge has same developer tools as Chromium, there is barely any reason to use FF or Chrome now.

I don't have any more hope for a browser that cannot fix a serious regression in 4 years. Censor this comment as much as you think is appropriate.

Comment 185

[u687153]

I am using https://addons.mozilla.org/en-GB/firefox/addon/tree-style-tab/ +1

Comment 186

[Stefan I.]

Yes. Voting is definitely needed. The function is very much in demand and forces you to use dirty hacks.

Comment 187

[erik.itland]

(In reply to Stefan I. from comment #186)

Yes. Voting is definitely needed. The function is very much in demand and forces you to use dirty hacks.

I realized today that there is actually a voting feature here under details. It isn't to obvious how to use it but you need to first click the "Vote" button in details, then check the checkbox "Vote For This Bug", then click the "Change My Votes"-button.

A little hassle but totally worth it I think.

Comment 188

[Petri Sirkkala]

(In reply to erik.itland from comment #187)

(In reply to Stefan I. from comment #186)

Yes. Voting is definitely needed. The function is very much in demand and forces you to use dirty hacks.

I realized today that there is actually a voting feature here under details. It isn't to obvious how to use it but you need to first click the "Vote" button in details, then check the checkbox "Vote For This Bug", then click the "Change My Votes"-button.

A little hassle but totally worth it I think.

I doubt voting will solve issue where the solution has been denied on security grounds earlier.

To me this issue looks like it should be taken action and either denied or escalated accordingly. I would expect there to be a board who has authority over such here.

Comment 189

[Danny Colin [:sdk]]

To me this issue looks like it should be taken action and either denied or escalated accordingly. I would expect there to be a board who has authority over such here.

If there's enough need for this but we haven't found an acceptable solution yet, I think it's totally fair to keep it in the backlog and re-explore the idea from time to time.

Also, Bugzilla isn't the best place to vote for things and see how big of an interest this feature is. Thankfully, we have a new feedback platform at https://connect.mozilla.org. I'd say we should submit the idea there and share it with the broader mozilla community so they can vote for it and we'll have a better idea of the importance of this issue so the team could re-prioritize it as needed.

Comment 191

[Diego Caravana]

Attachment: Connect top ideas

Comment 192

[Diego Caravana]

:sdk I'm afraid you're wrong about Connect.

As you can see here the most voted ideas on tabs (with thousands of votes) have gone completely ignored by Mozilla, no feedback in two years (except for a few useless comments by the poor community manager):

https://connect.mozilla.org/t5/ideas/idb-p/ideas/tab/most-kudoed

As Petri said correctly above, someone should have taken action and either denied or escalated the issue accordingly.

Except that, in fact, no one appears to have any kind of authority here.

Screenshot attached for the record.