1278984 - Add the font panel as an optional sidebar tab

Status: RESOLVED INVALID

(DevTools :: Inspector, enhancement, P2)

Description

[Julian Descottes [:jdescottes]]

Attachment: optional-font-panel.gif

The font panel was removed in Bug 1247723. Even though the panel can still be activated via about:config, it would be nice if users had an easier way to access it.

One of the comments in Bug 1247723 mentioned making the tab only accessible via the menu (which is only displayed when the tabs container has an overflow at the moment). 

I implemented a prototype based on this idea:
- sidebar tabs can now use an "optional" attribute
- a hidden optional tab is still listed in the sidebar menu
- a visible optional tab has a close icon
- clicking on the close icon of an optional tab hides it
- the sidebar menu button is now displayed if any of the tabs is optional and hidden (even if there is no overflow)

Using events emitted by the sidebar, the inspector panel can also store the visibility of the tab in user preferences.

(see the attachment)

Builds should be available at https://treeherder.mozilla.org/#/jobs?repo=try&revision=5219c8c92764 shortly.

Comment 1

[Julian Descottes [:jdescottes]]

Helen, what do you think about this? Even beyond the scope of the font panel, this could be a useful mechanism for handling additional/less-used panels.

Comment 2

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Julian Descottes [:jdescottes] from comment #1)
> Helen, what do you think about this? Even beyond the scope of the font
> panel, this could be a useful mechanism for handling additional/less-used
> panels.

I'd be all for this—the comments in bug 1247723 have been haunting me in my sleep. I agree this is also a good way to handle the less-used panels.

Wow, awesome job already having a build up!

Comment 3

[Brian Grinstead [:bgrins]]

Heads up that the sidebar component is being reimplemented / converted to HTML in Bug 1259819, so anything added here will need to be added in the new version too.

Comment 4

[yisibl]

@Julian Descottes Thanks!

Comment 5

[Julian Descottes [:jdescottes]]

Attachment: Bug 1278984 - Support optional tabs in sidebar component

Implementation of optional tabs using the XUL version of the sidebar.

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

Comment 6

[Julian Descottes [:jdescottes]]

For reference, uploaded the latest version of my patch here, using the XUL sidebar widget. 
As discussed with Honza, the HTML sidebar (Bug 1259819) should land in the coming weeks, I will then migrate this patch to the HTML version of the sidebar widget. No reason to land a XUL version in the meantime. 
(behavior is still as described on comment #1)

Other options/modifications discussed:
- keep the menu button always visible
- make all the tabs optional

Comment 7

[Marco Mucci [:MarcoM]]

Hi Julian, should this bug be part of Track #1?

Comment 8

[Julian Descottes [:jdescottes]]

IMO we don't have to track it in the devtools-html project. It is just an additional feature, and it makes more sense to wait for the HTML implementation of the sidebar to avoid implementing it twice. If we want to track it, that would be part of track #2 though, same as the blocking bug.

Comment 9

[Patrick Brosset <:pbro>]

Inspector bug triage (filter on CLIMBING SHOES).

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I have landed bug 1259819, converted Inspector side bar into HTML, and I'd like continue with converting the all-tabs menu (bug 1281789). I have been looking at this bug and I think we could simplify the UX here.

What about:
* The all tabs menu is available all the time.
* Every tab has corresponding item in the menu.
* The user can check/uncheck any item to show/hide any tab.
* There are no special 'optional' tabs (the user can show/hide any tab)
* The `Fonts` tab can be hidden/unchecked by default

This UX is consistent e.g. with how the Storage panel columns customization UX works (and Net panel should work the same).

Honza

Comment 11

[Julian Descottes [:jdescottes]]

(In reply to Jan Honza Odvarko [:Honza] from comment #10)
> I have landed bug 1259819, converted Inspector side bar into HTML, and I'd
> like continue with converting the all-tabs menu (bug 1281789). I have been
> looking at this bug and I think we could simplify the UX here.
> 
> What about:
> * The all tabs menu is available all the time.
> * Every tab has corresponding item in the menu.
> * The user can check/uncheck any item to show/hide any tab.
> * There are no special 'optional' tabs (the user can show/hide any tab)
> * The `Fonts` tab can be hidden/unchecked by default
> 
> This UX is consistent e.g. with how the Storage panel columns customization
> UX works (and Net panel should work the same).
> 
> Honza

Sounds good except for one point :

> * The user can check/uncheck any item to show/hide any tab.

There is one issue with this. The all-tabs-menu is supposed to allow you to select tabs that disappeared because of the overflow. Clicking a menu item here means "select this tab that I can't select otherwise". If clicking an item now toggles its visibility, how can a user select a tab that is configured to be displayed, but is hidden for overflow reasons?
The all-tabs-menu is primarily meant for navigation, not for configuration.

In my opinion, closing/hiding a tab has to remain separate from the menu.

Comment 12

[Patrick Brosset <:pbro>]

(In reply to Julian Descottes [:jdescottes] from comment #11)
> In my opinion, closing/hiding a tab has to remain separate from the menu.
Agreed. There might be a way to merge them though: at the bottom of the menu, have an "edit" item that, once clicked, puts checkboxes next to each menu item (also revealing the items that were hidden so far). So you can switch the menu to edit mode and change which item are shown in it.
Once an item is set to be visible in the menu, its corresponding tab appears in the sidebar.

Comment 13

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: menu.png

(In reply to Julian Descottes [:jdescottes] from comment #11)
> (In reply to Jan Honza Odvarko [:Honza] from comment #10)
> Sounds good except for one point :
> 
> > * The user can check/uncheck any item to show/hide any tab.
Yes, you are right.

(In reply to Patrick Brosset <:pbro> from comment #12)
> (In reply to Julian Descottes [:jdescottes] from comment #11)
> > In my opinion, closing/hiding a tab has to remain separate from the menu.
> Agreed. There might be a way to merge them though: at the bottom of the
> menu, have an "edit" item that, once clicked, puts checkboxes next to each
I like that.

I have also talked to Joe and he pointed out similar UI/UX in iTunes.

See the attached screenshot
- the image on the left shows a context menu with list of tabs
- it has 'Edit Menu...' item at the bottom
- when the user picks the 'Edit Menu...' there is additional popup allowing the user to pick tabs.

So, the UI is split into two parts. I. part allowing to select tabs and the II. part allowing to show/hide tabs.

If I understand correctly, Patrick's suggestion is about merging those two parts. I don't have a strong preference, I like both, except that split the logic into two parts might be simpler to implement (especially on top of the current Menu API we have available).

Honza

Comment 14

[Julian Descottes [:jdescottes]]

I like the "edit menu" option, opening a second menu as shown in your itunes example. 

(In reply to Jan Honza Odvarko [:Honza] from comment #13)
> 
> If I understand correctly, Patrick's suggestion is about merging those two
> parts. I don't have a strong preference, I like both, except that split the
> logic into two parts might be simpler to implement (especially on top of the
> current Menu API we have available).

Agreed, merging the two would require to implement a new Menu widget, maybe not ideal to start.

Comment 15

[Helen V. Holmes (:helenvholmes) (:✨)]

(In reply to Jan Honza Odvarko [:Honza] PTO 07/23 - 08/08 from comment #13)
> Created attachment 8772378 [details]
> menu.png
> 
> (In reply to Julian Descottes [:jdescottes] from comment #11)
> > (In reply to Jan Honza Odvarko [:Honza] from comment #10)
> > Sounds good except for one point :
> > 
> > > * The user can check/uncheck any item to show/hide any tab.
> Yes, you are right.
> 
> (In reply to Patrick Brosset <:pbro> from comment #12)
> > (In reply to Julian Descottes [:jdescottes] from comment #11)
> > > In my opinion, closing/hiding a tab has to remain separate from the menu.
> > Agreed. There might be a way to merge them though: at the bottom of the
> > menu, have an "edit" item that, once clicked, puts checkboxes next to each
> I like that.
> 
> I have also talked to Joe and he pointed out similar UI/UX in iTunes.
> 
> See the attached screenshot
> - the image on the left shows a context menu with list of tabs
> - it has 'Edit Menu...' item at the bottom
> - when the user picks the 'Edit Menu...' there is additional popup allowing
> the user to pick tabs.
> 
> So, the UI is split into two parts. I. part allowing to select tabs and the
> II. part allowing to show/hide tabs.
> 
> If I understand correctly, Patrick's suggestion is about merging those two
> parts. I don't have a strong preference, I like both, except that split the
> logic into two parts might be simpler to implement (especially on top of the
> current Menu API we have available).
> 
> Honza

The iTunes paradigm has been the one that we've been operating off of for overflow, and what we'd like to move towards for these sorts of issues.

I agree with everyone above me: sounds like a good way to handle this issue, although as Julian says, I don't know what that means for the implementation.

Comment 16

[Martin Balfanz [:mbalfanz]]

I think this is obsolete by now and can be closed. @pbro WDYT?

Comment 17

[Patrick Brosset <:pbro>]

Yes, good point. Let me close it now.