359483 - Create icon for 'tab menu' button on tab bar

Status: RESOLVED FIXED

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[froodian (Ian Leue)]

From bug 355490 comment 4:
> the decision was to have this
> menu behave like a pop-up, not a pull-down, so that the current tab is under
> the cursor when the menu appears. We'll have to think about what that means for
> the icon (in another bug)

Since we know what the desired behavior is, there's no need to wait for the code to land before we start working on a nice icon.

Jon, do you think you could make up a mockup of some icon ideas for this?

Comment 1

[Jon Hicks]

Sure. So we're not sure how this work, only that clicking the icon will reveal all tabs in some way?

Comment 2

[froodian (Ian Leue)]

As I understand it, the behavior is clear.  There'll be a widget.  Clicking It will reveal a menu, rooted at the tab that's currently open (with all tabs to the left above it, and all tabs to the right below it).  The way Desmond's been working on it (and I think probably the way it'll work) is that there'll also be two separators in the menu, dividing the visible tabs from the tabs sitting in overflow land on each side.

Comment 3

[froodian (Ian Leue)]

Bug 355490 has landed with a placeholder image, so this is ready to go (the image is resources/images/chrome/tab_menu_button.tif).  Some ideas from that bug:

From bug 355490 comment 10:
> Avoid using the same ">" triangle image we're using for scroll buttons, since
> the click action behavior each responds with is completely different.  The left
> and right scroll triangles do not display a menu and take action immediately. 
> A similar appearance might indicate similar behavior.  I think we should match
> behavior of NSToolbar's overflow menu control, the ">>", and just invert it
> downward.  This might present the user with something familiar and allow them
> to more intuitively realize that it displays a menu for clipped items.
> 
> Another possible enhancement is to draw a lighter gray area behind the control
> when the mouse is hovering over either scroll button or the overflow menu
> button, matching the hover appearance of the regular tab buttons. (e.g.
> drawTiledInRect:origin:operation: with "tab_hover.tif").  This also means
> tracking the entire rectangle on each end as opposed to only recognizing a
> click inside the actual image bounds (as we currently do).

From bug 355490 comment 13:
> since we're mimicking a popup menu, how about using the up/down arrow
> that those menus use?

Comment 4

[Stuart Morgan]

Another possibility would be something list-y, along the lines of the icon for the Bookmark Manager's sort menu.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

One of the things that bugs me about the current implementation is that the icon always looks disabled right now, except when you click on it (you see it turn black for a fraction of a second before the menu covers it up).

Since it's sitting right next to a scroll button (and since it's not the horizontal overflow >> metaphor), I think the "tabs" button needs to be black when you can click on it (which, for it, is all times it is visible), just like the scroll arrow is black when it can be clicked on.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(The actual shape/visual representation of the icon may depend on what we end up doing about the menu's behavior, i.e. bug 376930.)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

[6:20pm] smorgan: I think we should match the buttons if we do nothing else
[6:20pm] smorgan: by which I mean, use the same grey and embossing on the scroll and the menu buttons
[6:21pm] smorgan: Which would help with the "it looks disabled" issue
[6:23pm] smorgan: Anything beyond that probably waits for a refresh of the entire tab bar look

Comment 8

[Stuart Morgan]

Attachment: darker menu button

I took the existing image, darkened the grey, and brightened the etching on the bottom, so it fits better with the scroll arrows.

Comment 9

[Stuart Morgan]

Attachment: left arrow

While I was playing with images, there's a too-light "spur" on the top of each of the scroll arrows that's always bothered me, so I toned down that one pixel in each arrow.

Comment 10

[Stuart Morgan]

Attachment: right arrow

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 305234 [details]
darker menu button

r=ardissone; this is *so* much better!

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 305235 [details]
left arrow

I don't really notice any difference here, but if you like it better, then by all means r=ardissone :)

Comment 13

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH. Any further changes should be new bugs.