878546 - Menu-panel subviews styling

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, enhancement)

Comment 1

[u428464]

Oups hit enter too soon. Currently the different subviews (Help, History, etc) aren't very nice visually. They should be a bit redesigned. 

First the header doesn't seem to be very useful and isn't shown on mockups.

There is also a lot of wasted space under the different items in subview (especially in "help").

Concerning the history subview the "show all history" should have the same styling as the "clear history" and "restore previous sessions". When you have no history items in the subview it looks a bit weird, maybe having a "no history" text would be nice.

Introducing spacers as seen on the mockups would be nice too : http://people.mozilla.com/~shorlander/panel-experiment-03/panel-experiment.html

There may be other things to change. UX may have ideas too.

Comment 2

[u428464]

I forgot the fact that the shortcuts could be added to the right of the items as seen here : http://shorlander.dropmark.com/118810/1831622

All the entries should also be aligned to the left, even those that have no icons.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Not requiring for Australis:M7.

Comment 4

[Justin Dolske [:Dolske]]

Is there further work you wanted done here?

Comment 5

[Stephen Horlander [:shorlander]]

(In reply to Justin Dolske [:Dolske] from comment #4)
> Is there further work you wanted done here?

Yes. Will work up a more complete spec.

Comment 6

[Dão Gottwald [:dao]]

(In reply to Guillaume C. [:ge3k0s] from comment #2)
> All the entries should also be aligned to the left, even those that have no
> icons.

That's common style for menus on OS X but not on Windows, AFAIK. I'm not sure if there's one true answer for Linux.

Comment 7

[u428464]

Note that the styling from the arrowpanel menus when in toolbar is far from perfect too.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

(In reply to Stephen Horlander [:shorlander] from comment #5)
> (In reply to Justin Dolske [:Dolske] from comment #4)
> > Is there further work you wanted done here?
> 
> Yes. Will work up a more complete spec.

Was a more complete spec put somewhere?

Comment 9

[Stephen Horlander [:shorlander]]

(In reply to Mike Conley (:mconley) from comment #8)
> (In reply to Stephen Horlander [:shorlander] from comment #5)
> > (In reply to Justin Dolske [:Dolske] from comment #4)
> > > Is there further work you wanted done here?
> > 
> > Yes. Will work up a more complete spec.
> 
> Was a more complete spec put somewhere?

Not a complete spec but I included a cleaned up subview layout here: https://people.mozilla.org/~shorlander/mockups-interactive/australis-interactive-mockups/windows8.html (click on the History item in the menu panel)

Comment 10

[u428464]

It looks nice, but what about subviews that have a lot of empty space at the bottom (especially the Help subview) ?

Comment 11

[Mike de Boer [:mikedeboer]]

(In reply to Guillaume C. [:ge3k0s] from comment #10)
> It looks nice, but what about subviews that have a lot of empty space at the
> bottom (especially the Help subview) ?

I really like it too! I don't see the problem with 'a lot' of empty space at the bottom... it'll just keep being empty space (same as now). AFAIK, that's in accordance with subview semantics.

Comment 13

[Mike de Boer [:mikedeboer]]

Attachment: Patch 1: refresh the styling of sub-views

Comment 14

[:Gijs (he/him)]

Comment on attachment 8361924 [details] [diff] [review]
Patch 1: refresh the styling of sub-views

Review of attachment 8361924 [details] [diff] [review]:
-----------------------------------------------------------------

Generally, this looks alright, but I have a number of questions below so I'm withholding r+ for the moment.

::: browser/themes/shared/customizableui/panelUIOverlay.inc.css
@@ +17,5 @@
> +  border-right: 1px solid hsla(210,4%,10%,.2);
> +  border-left: 1px solid hsla(210,4%,10%,.2);
> +  box-shadow: 0 3px 5px hsla(210,4%,10%,.1),
> +              0 0 7px hsla(210,4%,10%,.1);
> +  color: #222426;

So we're choosing to hardcode all these colors irrespective of platform conventions or such? In particular for the foreground color, have you verified that it doesn't get overridden by more specific rules for menuitems and/or toolbarbuttons, on any of the platforms and menus we care about?

@@ +23,5 @@
>  }
>  
>  .panel-subviews:-moz-locale-dir(rtl) {
> +  box-shadow: 0 3px 5px hsla(210,4%,10%,.1),
> +              0 0 -7px hsla(210,4%,10%,.1);

If I'm reading https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow right, you're setting a negative blur radius, which is not allowed, and will either remove the shadow entirely or set it to have 0 blur. Pretty sure that's not what you want. Did you check this particular rule, and/or am I missing something?

@@ +40,5 @@
>  }
>  
> +.panel-subview-header,
> +.panel-subview-footer {
> +  padding: 15px 10px 10px;

Why more top than bottom padding? It looks like this for me: http://imgur.com/6Y6x1KB and doesn't match the spec as far as I can tell. This part didn't conflict, but perhaps it depended on something else that hasn't landed or was backed out?

@@ +42,5 @@
> +.panel-subview-header,
> +.panel-subview-footer {
> +  padding: 15px 10px 10px;
> +  height: 40px;
> +  background-color: hsla(210,4%,10%,.04);

This causes a color mismatch with the arrow above it.

I have another issue with this that is somewhat odd. It's about the hover styling. These items have the same hover styling as the 'regular' items. On my Windows machine, I can see it matches the mockup. However, while I can notice the difference in hover and non-hover styling clearly on my retina MBP, on my non-hidpi windows screen, the difference is so slight that I have trouble discerning it. Perhaps this has to do with the difference color profile. However, it makes me wonder if we should pick a correspondingly darker hover style for the headers.

I recognize this is probably something for Stephen, but I wanted to flag it just in case.

@@ +43,5 @@
> +.panel-subview-footer {
> +  padding: 15px 10px 10px;
> +  height: 40px;
> +  background-color: hsla(210,4%,10%,.04);
> +  font-size: 11px;

Don't do this. We're just in the process of reviewing the font sizes in bug 900428. It should be in em (1em should work, I think).

This also means you should alter the height here; the padding + height won't work well if the user's OS specifies larger/smaller font sizes. In fact, I'm not 100% sure the height needs setting at all; can't you just let layout determine this based on font size and padding, or am I missing something?

@@ +323,5 @@
>    display: none;
>  }
>  
>  panelview toolbarbutton,
> +panelview toolbarbutton.bookmark-item,

Why did you have to add this everywhere? Nodes that match this selector will also match the one above it - are we just having specificity wars here? Perhaps it'd make more sense to use a single class for toolbarbuttons in subviews, and substitute that for the "panelview toolbarbutton" selector?

There's also already a #BMB_bookmarksPopup > menu selector; is this all for the two incarnations of the bookmarks menu (in-menupanel, out-of-menupanel) ? Curses. :-(

@@ +350,5 @@
> +  -moz-padding-start: 0;
> +  text-align: center;
> +}
> +
> +.PanelUI-subView toolbarbutton:not(.panel-subview-footer) {

The above rules use child selectors, and these use descendant selectors. It seems haphazard; for extensibility, shouldn't we be using a descendant selector + class? (see my above suggestion about a single class for these as well)

Note also that this hunk doesn't seem to apply cleanly against current fx-team tip anymore. :-(

@@ +355,5 @@
> +  margin: 2px 0;
> +}
> +
> +.PanelUI-subView toolbarbutton:not(.panel-subview-footer) > .toolbarbutton-text {
> +  font-size: 12px;

Again, please don't fix this to px.

@@ +364,5 @@
> +  color: inherit;
> +}
> +
> +.PanelUI-subView toolbarbutton.bookmark-item@buttonStateHover@ {
> +  color: inherit !important;

Sadfaces.

Also, you had this style without !important before here without the hover state - what are we overriding and could we instead adapt that rule and avoid !important? Same question as regards the text-shadow.

@@ +370,5 @@
> +}
> +
> +.PanelUI-subView :-moz-any(menuseparator,toolbarseparator) {
> +  -moz-margin-start: -5px;
> +  -moz-margin-end: -4px;

Huh, why are these off by 1px?

Also, don't use :-moz-any as the last selector, certainly not in combination with a descendant selector: https://developer.mozilla.org/en-US/docs/Web/CSS/:any#Issues_with_performance_and_specificity .

Comment 15

[:Gijs (he/him)]

Also, patch 1 - is that v1 or is there more to be done here?

Comment 16

[Mike de Boer [:mikedeboer]]

(In reply to :Gijs Kruitbosch from comment #14)
> This causes a color mismatch with the arrow above it.

This is per spec. We have two options here:
1) file a follow-up that deals with this 'issue', so that Stephen gets the time to think of an alternative
2) introduce a linear gradient for the top 5px or so to transition from the arrow color to the bg color for now.

> I have another issue with this that is somewhat odd. It's about the hover
> styling. These items have the same hover styling as the 'regular' items. On
> my Windows machine, I can see it matches the mockup. However, while I can
> notice the difference in hover and non-hover styling clearly on my retina
> MBP, on my non-hidpi windows screen, the difference is so slight that I have
> trouble discerning it. Perhaps this has to do with the difference color
> profile. However, it makes me wonder if we should pick a correspondingly
> darker hover style for the headers.
> 
> I recognize this is probably something for Stephen, but I wanted to flag it
> just in case.

Perhaps, but I think we'd want to deal with this issue in a follow-up. I think it's lower prio than this bug.

> @@ +323,5 @@
> >    display: none;
> >  }
> >  
> >  panelview toolbarbutton,
> > +panelview toolbarbutton.bookmark-item,
> 
> Why did you have to add this everywhere? Nodes that match this selector will
> also match the one above it - are we just having specificity wars here?
> Perhaps it'd make more sense to use a single class for toolbarbuttons in
> subviews, and substitute that for the "panelview toolbarbutton" selector?
> 
> There's also already a #BMB_bookmarksPopup > menu selector; is this all for
> the two incarnations of the bookmarks menu (in-menupanel, out-of-menupanel)
> ? Curses. :-(

We already discussed this before. Marco was against adding classes to all bookmark toolbar items to mitigate our styling woes, so that's not really an option.

What I can do is:
```
%define subViewButton panelview toolbarbutton, panelview toolbarbutton.bookmark-item
```
...so that it looks less 'ugly'.

> @@ +364,5 @@
> > +  color: inherit;
> > +}
> > +
> > +.PanelUI-subView toolbarbutton.bookmark-item@buttonStateHover@ {
> > +  color: inherit !important;
> 
> Sadfaces.
> 
> Also, you had this style without !important before here without the hover
> state - what are we overriding and could we instead adapt that rule and
> avoid !important? Same question as regards the text-shadow.

Due to http://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/browser.css#202.
Since this is OSX only, I could duplicate this style to the OSX panel theme WITH !important flags and remove the !important flags here.

> @@ +370,5 @@
> > +}
> > +
> > +.PanelUI-subView :-moz-any(menuseparator,toolbarseparator) {
> > +  -moz-margin-start: -5px;
> > +  -moz-margin-end: -4px;
> 
> Huh, why are these off by 1px?

Due to content bleeding through at the end of the subview, causing a horizontal scrollbar to appear. reducing the margin by one makes the scrollbar go away, while keeping the separators full-width.
Can you think of a better way? (I hope so!)

Comment 17

[u428464]

(In reply to :Gijs Kruitbosch from comment #15)
> Also, patch 1 - is that v1 or is there more to be done here?

I think so. The content of the history subview for example is an ugly mess : the mockup is a bit better with the history items first, the tabs second and the windows last.

Comment 18

[Mike de Boer [:mikedeboer]]

My intention was to say v1, TBH... I'd prefer follow-ups for improvements to specific subviews.

Comment 19

[:Gijs (he/him)]

(In reply to Guillaume C. [:ge3k0s] from comment #17)
> (In reply to :Gijs Kruitbosch from comment #15)
> > Also, patch 1 - is that v1 or is there more to be done here?
> 
> I think so. The content of the history subview for example is an ugly mess :
> the mockup is a bit better with the history items first, the tabs second and
> the windows last.

Bug 928843 tracks the history view's specific issues. I agree with Mike that that shouldn't happen in this bug. It's difficult enough as it is.

Comment 20

[:Gijs (he/him)]

(In reply to Mike de Boer [:mikedeboer] from comment #16)
> (In reply to :Gijs Kruitbosch from comment #14)
> > This causes a color mismatch with the arrow above it.
> 
> This is per spec. We have two options here:
> 1) file a follow-up that deals with this 'issue', so that Stephen gets the
> time to think of an alternative
> 2) introduce a linear gradient for the top 5px or so to transition from the
> arrow color to the bg color for now.

I think we can file a followup. I actually just noticed that on current nightlies, the subviews also cause the arrow to not match. I don't like the idea of the gradient in what is otherwise intentially pretty 'flat' UI.

> > I have another issue with this that is somewhat odd. It's about the hover
> > styling. These items have the same hover styling as the 'regular' items. On
> > my Windows machine, I can see it matches the mockup. However, while I can
> > notice the difference in hover and non-hover styling clearly on my retina
> > MBP, on my non-hidpi windows screen, the difference is so slight that I have
> > trouble discerning it. Perhaps this has to do with the difference color
> > profile. However, it makes me wonder if we should pick a correspondingly
> > darker hover style for the headers.
> > 
> > I recognize this is probably something for Stephen, but I wanted to flag it
> > just in case.
> 
> Perhaps, but I think we'd want to deal with this issue in a follow-up. I
> think it's lower prio than this bug.

Sure.

> > @@ +323,5 @@
> > >    display: none;
> > >  }
> > >  
> > >  panelview toolbarbutton,
> > > +panelview toolbarbutton.bookmark-item,
> > 
> > Why did you have to add this everywhere? Nodes that match this selector will
> > also match the one above it - are we just having specificity wars here?
> > Perhaps it'd make more sense to use a single class for toolbarbuttons in
> > subviews, and substitute that for the "panelview toolbarbutton" selector?
> > 
> > There's also already a #BMB_bookmarksPopup > menu selector; is this all for
> > the two incarnations of the bookmarks menu (in-menupanel, out-of-menupanel)
> > ? Curses. :-(
> 
> We already discussed this before. Marco was against adding classes to all
> bookmark toolbar items to mitigate our styling woes, so that's not really an
> option.
> 
> What I can do is:
> ```
> %define subViewButton panelview toolbarbutton, panelview
> toolbarbutton.bookmark-item
> ```
> ...so that it looks less 'ugly'.

No, my issue is with the rule, not with the ugliness. :-)

I think our previous discussion was specifically about the bookmarks view. My point now wasn't about this, but about making all our views use an identical class that we can use for styling. The current mishmash of selectors isn't very nice. :-(

The bookmarks view, in that case, would only apply this class to whatever items it generates in the subview when used from the menu panel. I would not expect Marco to object to this, although I could be wrong, of course.

> > @@ +364,5 @@
> > > +  color: inherit;
> > > +}
> > > +
> > > +.PanelUI-subView toolbarbutton.bookmark-item@buttonStateHover@ {
> > > +  color: inherit !important;
> > 
> > Sadfaces.
> > 
> > Also, you had this style without !important before here without the hover
> > state - what are we overriding and could we instead adapt that rule and
> > avoid !important? Same question as regards the text-shadow.
> 
> Due to
> http://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/browser.
> css#202.
> Since this is OSX only, I could duplicate this style to the OSX panel theme
> WITH !important flags and remove the !important flags here.

Can we also not re-set the color: inherit and just rely on the non-hover style to take care of this? Or do we have separate styles for this on Windows and Linux as well? Anyhow, to avoid duplicating it, I would split it out entirely in this case (hoping that we wouldn't need it at all on Windows/Linux...).

> > @@ +370,5 @@
> > > +}
> > > +
> > > +.PanelUI-subView :-moz-any(menuseparator,toolbarseparator) {
> > > +  -moz-margin-start: -5px;
> > > +  -moz-margin-end: -4px;
> > 
> > Huh, why are these off by 1px?
> 
> Due to content bleeding through at the end of the subview, causing a
> horizontal scrollbar to appear. reducing the margin by one makes the
> scrollbar go away, while keeping the separators full-width.
> Can you think of a better way? (I hope so!)

I need to look into it, and I can't right now. Leave it for now and I'll look again for the next version of the patch; I have too much else on my plate right now.

Comment 21

[Mike de Boer [:mikedeboer]]

Attachment: Patch 1.1: refresh the styling of sub-views

Asking for feedback, because I'd like to know if this is the direction you were thinking.

It gets rather involved, introducing this new class.

Comment 22

[Mike de Boer [:mikedeboer]]

Comment on attachment 8363720 [details] [diff] [review]
Patch 1.1: refresh the styling of sub-views

discussed on IRC. Feedback was well-received.

Comment 23

[Mike de Boer [:mikedeboer]]

Attachment: Patch 1.2: refresh the styling of sub-views

Comment 24

[:Gijs (he/him)]

Comment on attachment 8363860 [details] [diff] [review]
Patch 1.2: refresh the styling of sub-views

Review of attachment 8363860 [details] [diff] [review]:
-----------------------------------------------------------------

Almost there. :-)

::: browser/themes/osx/browser.css
@@ +158,5 @@
>  }
>  
>  /* ----- BOOKMARK BUTTONS ----- */
>  
> +toolbarbutton.bookmark-item:not(.subviewbutton),

Are these necessary? I thought you said they weren't? Or is this just to avoid the !important?

@@ +199,5 @@
>    background-color: rgba(0, 0, 0, .205);
>  }
>  
> ++toolbarbutton.bookmark-item:hover:not(.subviewbutton),
> ++toolbarbutton.bookmark-item[open="true"]:not(.subviewbutton) {

Same as above

::: browser/themes/shared/customizableui/panelUIOverlay.inc.css
@@ +39,5 @@
> +.panel-subview-header,
> +.subviewbutton.panel-subview-footer {
> +  padding: 12px;
> +  background-color: hsla(210,4%,10%,.04);
> +  font-size: 1em;

Is specifying this font size necessary? :-)

@@ +344,5 @@
>  #customization-palette .toolbarbutton-text {
>    display: none;
>  }
>  
>  panelview toolbarbutton,

I think: panelview .toolbarbutton-1:not([type="menu-button"])

@@ +350,5 @@
>  #widget-overflow-list > toolbarbutton,
>  .customizationmode-button,
>  #edit-controls@inAnyPanel@ > toolbarbutton,
>  #zoom-controls@inAnyPanel@ > toolbarbutton,
>  #BMB_bookmarksPopup > menu,

Are these still necessary?

@@ +377,5 @@
> +  margin: 2px 0;
> +}
> +
> +.PanelUI-subView .subviewbutton:not(.panel-subview-footer) > .toolbarbutton-text {
> +  font-size: 1.1em;

I think this is wrong; they should be just as big as the items in the main view, right? 11px on OS X / Windows? That's 1em... In which case you should be able to just not specify this.

@@ +396,5 @@
>  #widget-overflow-list > toolbarbutton {
>    margin-top: 6px;
>  }
>  
>  panelview toolbarbutton@buttonStateHover@,

I think this can be .toolbarbutton-1:not([type="menu-button"]), while we're here.

@@ +402,5 @@
>  #widget-overflow-list > toolbarbutton@buttonStateHover@,
>  .customizationmode-button,
>  #edit-controls@inAnyPanel@ > toolbarbutton@buttonStateHover@,
>  #zoom-controls@inAnyPanel@ > toolbarbutton@buttonStateHover@,
>  #BMB_bookmarksPopup > menu@buttonStateHover@,

Are these still necessary? Doesn't the bookmarks menu code give these the same class, and aren't they also in a panelview?

@@ +414,5 @@
>  #zoom-controls@inAnyPanel@@buttonStateHover@ {
>    border-color: hsla(210,4%,10%,.1);
>  }
>  
>  panelview toolbarbutton@buttonStateActive@,

Ditto

@@ +420,5 @@
>  .customizationmode-button@buttonStateActive@,
>  #widget-overflow-list > toolbarbutton@buttonStateActive@,
>  #edit-controls@inAnyPanel@ > toolbarbutton@buttonStateActive@,
>  #zoom-controls@inAnyPanel@ > toolbarbutton@buttonStateActive@,
>  #BMB_bookmarksPopup > menu@buttonStateActive@,

Ditto.

Comment 25

[Mike de Boer [:mikedeboer]]

(In reply to :Gijs Kruitbosch from comment #24)
> Almost there. :-)

\o/

> Are these necessary? I thought you said they weren't? Or is this just to
> avoid the !important?

They are necessary to not apply the border-radius and bold font weight, as they are rather ugly to begin with. None of the rules in panelUIOverlay.inc.css override these, so I opted to make these more specific to avoid adding more code there.

> @@ +199,5 @@
> >    background-color: rgba(0, 0, 0, .205);
> >  }
> >  
> > ++toolbarbutton.bookmark-item:hover:not(.subviewbutton),
> > ++toolbarbutton.bookmark-item[open="true"]:not(.subviewbutton) {
> 
> Same as above

These are necessary to avoid the `important!`.

> @@ +377,5 @@
> > +  margin: 2px 0;
> > +}
> > +
> > +.PanelUI-subView .subviewbutton:not(.panel-subview-footer) > .toolbarbutton-text {
> > +  font-size: 1.1em;
> 
> I think this is wrong; they should be just as big as the items in the main
> view, right? 11px on OS X / Windows? That's 1em... In which case you should
> be able to just not specify this.

In the mockup, Stephen made the text size noticeably bigger than the default text size (1em, or 11px in his mockup). http://people.mozilla.org/~shorlander/mockups-interactive/australis-interactive-mockups/windows8.html

Comment 26

[Mike de Boer [:mikedeboer]]

Attachment: Patch 1.3: refresh the styling of sub-views

Comment 27

[:Gijs (he/him)]

Comment on attachment 8364299 [details] [diff] [review]
Patch 1.3: refresh the styling of sub-views

Review of attachment 8364299 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM!

::: browser/themes/shared/customizableui/panelUIOverlay.inc.css
@@ +335,5 @@
>    display: none;
>  }
>  
> +panelview .toolbarbutton-1,
> +.panelUI-grid .toolbarbutton-1 > .toolbarbutton-menubutton-button,

I'm not sure what this line will do without the other rules in that patch, so you may want to leave it out.

@@ +411,3 @@
>  .customizationmode-button@buttonStateActive@,
>  #widget-overflow-list > toolbarbutton@buttonStateActive@,
>  #edit-controls@inAnyPanel@ > toolbarbutton@buttonStateActive@,

AIUI, you can change the #widget-overflow-list to use .widget-overflow-list with a descendant selector and .toolbarbutton-1, and then you can remove the edit-controls/zoom-controls rules here. You might be able to clear up other bits as well. Anyway, that's probably best off in a followup.

Comment 28

[Mike de Boer [:mikedeboer]]

I wasn't able to remove the edit-/zoom-controls code.

remote: https://hg.mozilla.org/integration/fx-team/rev/04b6213da4e1

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/04b6213da4e1

Comment 30

[Roman Müller]

I have a few notes related to latest menu-panel subview styling.

1. When I click on any button which brings up subview (history, dev tools, help) it shows scroll bar on the right side of subview for a brief moment even if it is not needed. Then it disappears. This looks cheap. Check this screenshot where u can see scroll bar before it disappears:

http://fii.cz/azfdjcyn

2. Right border of menu panel is like 1px thick. When any subview is being summoned (history, dev tools, help) the right border becomes thicker. Again it looks cheap when subview is being animated. You can clearly see change of border thickness when switching between any subview and menu panel itself.

Menu panel with 1px thick right corner: http://fii.cz/shdkwvce
Subview with thicker right corner: http://fii.cz/bpambp

3. Why is padding on all subviews so huge? My history cant even fit to my 1080p monitor, therefore scroll bar is needed and even then I cant scroll down to show all history button because it's hidden behind Windows panel. See this screenshot:

http://fii.cz/mwcpvrx

I had to fix this with custom css styling to reduce padding.

4. Headers should be removed from subviews imho. They take way too much space while while not being needed at all.

Comment 31

[Bogdan Maris, Desktop Test Engineering]

Tested on Windows 8 32bit, Mac OS X 10.9.1 and Ubuntu 13.10 64bit using latest Aurora. The menu changes done to the menu look as expected.

For comment 30
1. Fixed - the scroll bar does not appear anymore.
2. Fixed - the border has the same thickness. 
3. Fixed - Only 25 history items are displayed in the History menu.
4. Maybe log an enhancement on that.