Open Bug 1332447 Opened 7 years ago Updated 1 month ago

API to hide the tabstrip

Categories

(WebExtensions :: Frontend, enhancement, P3)

enhancement

Tracking

(Not tracked)

webextensions ?

People

(Reporter: ntim, Unassigned)

References

(Depends on 1 open bug, Blocks 4 open bugs)

Details

(Keywords: DevAdvocacy, Whiteboard: [triaged][tabs])

Attachments

(6 files, 3 obsolete files)

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.
Component: Toolbars and Customization → WebExtensions: General
Product: Firefox → Toolkit
Whiteboard: [design-decision-needed]
(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.
Component: WebExtensions: General → WebExtensions: Frontend
Whiteboard: [design-decision-needed] → [design-decision-needed][advisory-group]
(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.
Summary: Provide a built-in way to hide navigation bar and tabs bar → WebExtension API to move/hide toolbars
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?
(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.
Flags: needinfo?(dolske)
> 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.
(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.
(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.
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.
Summary: WebExtension API to move/hide toolbars → WebExtension API to hide the tabstrip
webextensions: --- → ?
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.
Keywords: DevAdvocacy
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
(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.
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.
Flags: needinfo?(dolske)
Flags: needinfo?(kev)
Assignee: nobody → kev
Whiteboard: [design-decision-needed][advisory-group] → [advisory-group]
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.
Assignee: kev → nobody
Priority: -- → P2
Whiteboard: [advisory-group] → [triaged]
Assignee: nobody → ntim.bugs
Assignee: ntim.bugs → nobody
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/...).
That's what I was originally thinking (and would prefer) as well, I was just going off the proposal.
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 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.
(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.
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.
(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?
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?
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.
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#
Flags: needinfo?(amckay)
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.
Flags: needinfo?(amckay)
Attached image Capture.PNG
No longer blocks: 1367160
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;
    }
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 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.
Attachment #8899203 - Flags: review?(mixedpuppy)
Comment on attachment 8899203 [details]
Bug 1332447 part 2 - Implementation of the tabstrip hidding API.

Sorry for the spam!
Attachment #8899203 - Flags: review?(mixedpuppy)
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?
Flags: needinfo?(ptheriault)
Comment on attachment 8899202 [details]
Bug 1332447 part 1 - Pass context to callOnClose() callback.

Seems ok, want feedback from Kris.
Attachment #8899202 - Flags: feedback?(kmaglione+bmo)
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 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.
Attachment #8899203 - Flags: review?(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.
Attachment #8899203 - Flags: feedback?(gijskruitbosch+bugs)
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.
> 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.^^)
(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.
(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 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.
Attachment #8899203 - Flags: feedback?(gijskruitbosch+bugs) → feedback-
(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?
(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?
> 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.
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 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 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.
(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.
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.
> 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.
Blocks: 1226546
Flags: needinfo?(kev)
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?
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.
(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.
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.
Flags: needinfo?(jgriffiths)
Flags: needinfo?(mconca)
The discussion here needs to be between UX and Mike, clearing my needinfo
Flags: needinfo?(jgriffiths)
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.
(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.
(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.
(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.
(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).
(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.
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.
Flags: needinfo?(mconca)
(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.
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.
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.
(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. :-)
> 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>
(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.
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?
> 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 :)
> 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.
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?
Flags: needinfo?(aswan)
Attachment #8917571 - Flags: feedback?(bwinton)
(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.
Flags: needinfo?(aswan)
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.
(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...
Yeah, this does look nicer.
Attachment #8899203 - Attachment is obsolete: true
Attachment #8899202 - Attachment is obsolete: true
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.
Why is it not possible with the context menu to hide/show the tabs bar?
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 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…
Attachment #8917570 - Flags: review?(bwinton) → review?(mixedpuppy)
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…
Attachment #8917571 - Flags: review?(bwinton) → review?(mixedpuppy)
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…
Attachment #8917697 - Flags: review?(bwinton) → review?(mixedpuppy)
> 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?
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?
Depends on: 1408053
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 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.
(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.
(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…
(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.
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...
> 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.
> * 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.)
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.
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.
(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 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
Attachment #8917571 - Flags: review?(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.
Attachment #8917697 - Flags: review?(mixedpuppy)
Attachment #8917570 - Flags: review?(mixedpuppy)
(Removing need info as I've provided security input elsewhere)
Flags: needinfo?(ptheriault)
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.
Blocks: 1410548
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.
(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.
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.
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.
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.
(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/)
(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.
Severity: normal → enhancement
Summary: WebExtension API to hide the tabstrip → API to hide the tabstrip
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.
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
(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)
(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
(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.
(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.
Priority: P2 → P3
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.
Whiteboard: [triaged] → [triaged][tabs]
Attachment #8841190 - Attachment is obsolete: true
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.
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. :)
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
Product: Toolkit → WebExtensions
Might have become a bit easier with bug 1356920 fixed.
Depends on: 1356920
(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!
(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
(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.
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.
(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.
See Also: → 1512802
See Also: → mult_sessions2
See Also: → mult_sessions1

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.

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

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.

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

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.

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

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

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.

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.)

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

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

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

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

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.

Severity: normal → S3
Duplicate of this bug: 1880711
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: