The default bug view has changed. See this FAQ.
Last Comment Bug 1332447 - WebExtension API to hide the tabstrip
: WebExtension API to hide the tabstrip
Status: NEW
[design-decision-needed][advisory-group]
: DevAdvocacy
Product: Toolkit
Classification: Components
Component: WebExtensions: Frontend (show other bugs)
: unspecified
: Unspecified Unspecified
-- normal with 9 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andy McKay [:andym]
Mentors:
Depends on:
Blocks: webextensions-additional-apis 1339561
  Show dependency treegraph
 
Reported: 2017-01-19 13:13 PST by Tim Nguyen :ntim
Modified: 2017-03-21 12:31 PDT (History)
19 users (show)
gijskruitbosch+bugs: needinfo? (dolske)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
?


Attachments
Proposal (2.21 KB, text/plain)
2017-02-25 06:27 PST, Tim Nguyen :ntim
no flags Details

Description User image Tim Nguyen :ntim 2017-01-19 13:13:46 PST
Since WebExtensions are unlikely going to support hiding built-in toolbars (since toolbar IDs may change with updates and stuff), I think it makes sense to support a built-in way to hide the navigation bar and the tab bar.

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

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

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

Or if a toolbar add-on is detected, the customization mode could reveal those options, although that would be confusing.
Comment 1 User image Andy McKay [:andym] 2017-01-19 13:25:32 PST
I think the ability to hide these elements could be exposed as a WebExtension API. A common use case, with lots of rabid users is a vertical tab solution. We are providing an API to allow sidebars, so an extension could provide there own tab implementation in HTML and JS... but they would need to hide the existing tabs. 

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

A vertical tab solution is on the WebExtension list of add-ons we'd like to have support for, so interested in that one.
Comment 2 User image :Gijs 2017-01-25 07:34:41 PST
(In reply to Andy McKay [:andym] from comment #1)
> People have told me that hiding the tabs also removes a lot of the events
> because those are tied to the XUL. 

Hiding the navigation toolbar does the same thing - it breaks a bunch of builtin Firefox features (cf. bug 1227540 + dupes), and we unshipped the "open location" dialog so if the navigation toolbar is hidden, the user can't use the location bar to navigate (and therefore various other things break, like the page permissions notifications which are anchored in the location bar).
Comment 3 User image Croydon 2017-02-06 06:02:42 PST
I rely on that in order to port Vertical Tabs Reloaded.
Comment 4 User image Tim Nguyen :ntim 2017-02-25 06:27:15 PST
Created attachment 8841190 [details]
Proposal

Shane, can you take a look at this proposal?

It covers:
- Moving built-in toolbars around
- Hiding built-in toolbars
- Registering new toolbars
Comment 5 User image Tim Nguyen :ntim 2017-02-25 06:29:06 PST
I'm very bad at naming, perhaps "browser_region_tweak" could be named in a better way.
Comment 6 User image Shane Caraveo (:mixedpuppy) 2017-02-25 14:20:35 PST
Comment on attachment 8841190 [details]
Proposal

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

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

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

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

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

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

Don't recall if I mentioned this to you: https://github.com/mixedpuppy/web-ext-panels
Comment 7 User image Kris Maglione [:kmag] 2017-02-25 14:28:39 PST
(In reply to :Gijs (away until Feb 27) from comment #2)
> Hiding the navigation toolbar does the same thing - it breaks a bunch of
> builtin Firefox features (cf. bug 1227540 + dupes), and we unshipped the
> "open location" dialog so if the navigation toolbar is hidden, the user
> can't use the location bar to navigate (and therefore various other things
> break, like the page permissions notifications which are anchored in the
> location bar).

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

For the case of focusing the location bar when it's hidden (via Ctrl+L/⌘-L or similar), we should probably just use similar auto-hiding behavior to what we do for the hidden menu bar and the location bar in full screen mode. For notifications, we may be able to come up with something better.
Comment 8 User image Tim Nguyen :ntim 2017-02-25 15:46:26 PST
(In reply to Shane Caraveo (:mixedpuppy) from comment #6)
> Comment on attachment 8841190 [details]
> Proposal
> 
> I think this is a good start on a definition of what would be wanted, and
> what issues or limitations should be in place.  Whether it is a manifest
> addition or an api is less important right now.
> 
> What about showing something that is hidden (e.g. Personal Toolbar)?
We could do either:
- Show on install, and if the user hides it manually, it stays hidden (eg. simply toggle on the pref that hides the personal toolbar on install)
- Disable the menu item to hide it, and say it was hidden by an add-on somehow
- Not support showing/hiding toolbars which the hidden state is controlled by the browser (find-bar/personal toolbar)
Initially we could limit this to hiding the tabbar (the most common use-case for this), once that's done, we can think out the details for other toolbars.

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

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

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

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

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

I think support for customizable toolbars is really important as a lot of people as using CTR for the add-on bar, and Status-4-Evar to get a status bar back.
Comment 9 User image :Gijs 2017-02-26 14:15:55 PST
(In reply to Kris Maglione [:kmag] from comment #7)
> (In reply to :Gijs (away until Feb 27) from comment #2)
> > Hiding the navigation toolbar does the same thing - it breaks a bunch of
> > builtin Firefox features (cf. bug 1227540 + dupes), and we unshipped the
> > "open location" dialog so if the navigation toolbar is hidden, the user
> > can't use the location bar to navigate (and therefore various other things
> > break, like the page permissions notifications which are anchored in the
> > location bar).
> 
> We do currently support opening windows without tab strips or a location
> bar, and we hide both in full screen mode, so these are issues we should fix
> in any case.

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

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

This is really not trivial.

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

Allowing add-ons to hide the navbar paints us back into a corner we're struggling to get out of. We shouldn't do it.
Comment 10 User image Tim Nguyen :ntim 2017-03-02 16:05:30 PST
(In reply to :Gijs from comment #9)
I think hiding the nav-bar is off the hook for now, since it contains sensitive security information.

Though, the minimum here should be hiding the tab bar, since add-ons like Tab Center rely on it.
Comment 11 User image Andy McKay [:andym] 2017-03-02 17:49:47 PST
I think the call should be made by the Firefox front end team, because hiding the tab bar is something they'll have to maintain and support. If it happens the WebExtensions team will do whatever it can to help. So I'm looking at Gijs and team here, also should I move this bug somewhere else? Is there any more information we can provide as to why we think this will be a good idea?
Comment 12 User image :Gijs 2017-03-03 02:52:29 PST
(In reply to Andy McKay [:andym] from comment #11)
> I think the call should be made by the Firefox front end team, because
> hiding the tab bar is something they'll have to maintain and support. If it
> happens the WebExtensions team will do whatever it can to help. So I'm
> looking at Gijs and team here, also should I move this bug somewhere else?
> Is there any more information we can provide as to why we think this will be
> a good idea?

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

Hiding the tabstrip is less painful than hiding the navbar, so I think we could consider it, whereas the nav-bar is just... ugh. I don't know how hard maintaining it would be, exactly. I expect it would be an easier call if there was a commitment from the webextensions team to do some of that work.
Comment 13 User image Johann Hofmann [:johannh] 2017-03-03 03:22:27 PST
> Hiding the tabstrip is less painful than hiding the navbar, so I think we could consider it, whereas the nav-bar is just... ugh. I don't know how hard maintaining it would be, exactly. I expect it would be an easier call if there was a commitment from the webextensions team to do some of that work.

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

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

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

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

Ah, I see. Thanks for the clarification! Yes, I agree with the above statement. Hiding the tabbar would be nice, but it's hard to say how much work it requires.
Comment 16 User image Andy McKay [:andym] 2017-03-03 10:27:02 PST
I think we are all in agreement that the hiding the navigation bar wouldn't be a acceptable from a security point of view, so let's stop talking about that and stick to the tabs bar. Yup, the WebExtensions team will help.
Comment 17 User image Dan Callahan [:callahad] 2017-03-07 12:37:05 PST
FWIW, Devrel is frequently seeing this request, requests that would require this, and users presuming that such an API can be taken for granted. We'd be happy to help promote this API when implemented.
Comment 18 User image Tim Nguyen :ntim 2017-03-19 10:28:34 PDT
Chrome has a chrome_ui_overrides manifest fields, though I don't really like it, because there's no support for dynamic changes (you can't hide the tabbar when there's only one tab, or do similar stuff like that).

https://developer.chrome.com/extensions/ui_override
Comment 19 User image Croydon 2017-03-19 10:50:27 PDT
(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.

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