494832 - [Mac] Back/forward dropdown always looks disabled (replace drop-down arrow on navigation and bookmark toolbar)

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Jesse Ruderman]

Attachment: screenshots

Now that bug 462644 is fixed, the dropdown next to the back/forward buttons always looks disabled to me.  I think it should be blacker when it is enabled.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

I honestly don't know if we care, though I suppose it would be nice.

Comment 2

[Shawn Wilsher :sdwilsh]

Is that a before-after picture?  It's not clear what you are referring to here.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

This was intentional, and is an instance of aesthetic design winning over purely interactive design.  The drop down (when active) now matches the small circle used to resize the search bar.  This looks kind of disabled, and the disabled state is even more visually obfuscated.  This visual design is also currently a compromise between what we had in Firefox 3, and deleting the control entirely.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

Perhaps we should make the disabled state lighter.  I don't want to draw attention to the drop down, but normal vs. disabled does need to be apparent.

Comment 5

[Shawn Wilsher :sdwilsh]

(In reply to comment #2)
> Is that a before-after picture?  It's not clear what you are referring to here.
disregard this - I got it now.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

Another option is to simply remove the drop down when it is disabled.

Comment 7

[juan becerra [:juanb]]

 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre

If you use Personas and are using one, the problem seems a little more obvious.

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

I thought personas had a completely custom set of toolbar icon graphics (transparent, better highlighting to work on multiple backgrounds, etc.)

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Why we behave differently as for all the other dropdown arrows in the UI? All of them have a black background when they are enabled.

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

can you name another enabled/disabled drop down arrow on OS X?  I think we might want to make the disabled state lighter to make the difference clearer, but even having this arrow in the first place is already breaking precedent.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

See the bookmarks toolbar. Those dropdowns aren't disabled but the one from the "Most Visited" saved search is positioned directly beneath. I cannot see the back/forward dropdown as active.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: some options

Here are some options of things we can potentially do.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Plan

I spent some time with beltzner this evening going through a lot of different levels of grey so that we could get this right.  Here is what we think works best.

1) Keyhole drop down is also used in bookmarks toolbar for consistency, and so the user can see the same image is clearly enabled in two examples below

2) Enabled state got darker, disabled state got lighter (75%) so there is now more of a difference

3) we kept the recessed, pushed in look.  This makes the UI appear more carefully constructed, and feels less GIF.

Comment 14

[Alex Faaborg [:faaborg] (Firefox UX)]

I'll have files for an image drop shortly, beltzner provided ui-r over IM

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

>See the bookmarks toolbar. Those dropdowns aren't disabled but the one from the
>"Most Visited" saved search is positioned directly beneath.

sorry, I thought I had already mentioned that we were going to match them (turns out that was in email).  What I meant was that external consistency has no precedent for a drop down arrow applied directly to the main toolbar, so we are kind of making this up as we go.

Sorry about the confusion, also comment #8 clearly didn't arrive at the bug it was meant for.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: New bookmarks toolbar arrow

This should replace the file /source/browser/themes/pinstripe/browser/places/folderDropArrow.png

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: New Toolbar.png

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: New Toolbar-rtl.png

Comment 19

[Alex Faaborg [:faaborg] (Firefox UX)]

Note that in these three files I dropped the transparency on the bottom of the active drop down (it previously had been blending with the background) in order to give the drop down a consistent appearance on different backgrounds.

Comment 20

[Dão Gottwald [:dao]]

These files are again darker than they should be.
https://bug494832.bugzilla.mozilla.org/attachment.cgi?id=380067
http://hg.mozilla.org/mozilla-central/raw-file/c569f6c33f05/browser/themes/pinstripe/browser/Toolbar.png

Comment 21

[Alex Faaborg [:faaborg] (Firefox UX)]

Odd, I opened the files with the edited gAMA chunk in photoshop, did the edits, and saved back out to a png.  How did you adjust the gAMA chunk last time, and do you think that is what we need to repeat again?

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

specifically I mean this action: https://bugzilla.mozilla.org/show_bug.cgi?id=462644#c34

Comment 23

[Dão Gottwald [:dao]]

Attachment: New Toolbar.png

Comment 24

[Dão Gottwald [:dao]]

Attachment: New Toolbar-rtl.png

Comment 25

[Dão Gottwald [:dao]]

I used a tool called tweakpng to add the gAMA chunk (it was completely absent again).

Comment 26

[Alex Faaborg [:faaborg] (Firefox UX)]

Thanks, at some point after we ship we should adjust the source files so that they look right with the chunk removed and this doesn't happen again. But right now I don't want to add any additional complexity to the update.

Comment 27

[Alex Faaborg [:faaborg] (Firefox UX)]

We need to make sure this gets landed before RC to address the current usability issue.

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 380083 [details]
New Toolbar.png

a191=beltzner

Comment 29

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/5c6e5b91d208

Comment 30

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/51e44d86d59a

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #15)
> sorry, I thought I had already mentioned that we were going to match them
> (turns out that was in email).  What I meant was that external consistency has
> no precedent for a drop down arrow applied directly to the main toolbar, so we
> are kind of making this up as we go.

Does that mean we don't use the exact same color? I have to re-ask because the answer is a bit unclear for me and I can still see a difference in the darkness for the back/forward dropdown and all the others with todays builds on trunk and 1.9.1.

Comment 32

[Justin Dolske [:Dolske]]

Attachment: Screenshot, current nightly.

Hmm. I don't think this got fixed quite right. Comment 13 seems to be saying that the arrow should be the same as the bookmarks toolbar (shape and color? or just shape?), but it's noticeably lighter on my system. I stumbled in here for the same reason Jesse did in comment 0 -- it looks like the arrow is in a disabled state (when it's actually enabled), and I thought it was broken.

Comment 33

[Alex Faaborg [:faaborg] (Firefox UX)]

Did we not check in https://bugzilla.mozilla.org/attachment.cgi?id=380066 to replace /browser/themes/pinstripe/browser/places/folderDropArrow.png

Comment 34

[Dão Gottwald [:dao]]

No.

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So shall we reopen this bug? Otherwise it can get lost (when it's not too late already).

Comment 36

[Mike Beltzner [:beltzner, not reading bugmail]]

No. We should file a new bug, called "new bookmark drop-down image", and attach the attachment on it. We should do it immediately, mark it a blocker, get it reviewed and landed ASAP.

We should also take this as a lesson as to why "simple image drop in" carries a large regression risk, nonetheless! :)

Comment 37

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 380066 [details]
New bookmarks toolbar arrow

a191=beltzner; or, fine, do it this way, too.

Comment 38

[Alex Faaborg [:faaborg] (Firefox UX)]

either way, we also have the follow up bug 496047

Comment 40

[Mike Beltzner [:beltzner, not reading bugmail]]

Can someone test this to make sure it works OK and then check it in?

Comment 41

[Justin Dolske [:Dolske]]

Ugh, why are we putting gamma chunks in our theme images? Seems like that's going to be a headache, and cause further pain like this.

I'll look at adding it to folderDropArrow.png in the meantime, though.

Comment 42

[Dão Gottwald [:dao]]

(In reply to comment #36)
> We should also take this as a lesson as to why "simple image drop in" carries a
> large regression risk, nonetheless! :)

In this case it hasn't regressed anything, though.

(In reply to comment #41)
> Ugh, why are we putting gamma chunks in our theme images? Seems like that's
> going to be a headache, and cause further pain like this.

Because it was there before, and dropping it would make the toolbar buttons darker compared to Firefox 3.

Comment 43

[Justin Dolske [:Dolske]]

Attachment: folderDropArrow.png w/gAMA=0.5500

Comment 44

[Justin Dolske [:Dolske]]

Attachment: Comparison of trunk, patch

"Before" is current trunk, "After" is with the g=0.55 folderDropArrow.png (attachment 381225 [details]). I hope there are no other arrows that needed to match this color?

Comment 45

[Justin Dolske [:Dolske]]

folderDropArrow.png change pushed:

to trunk: http://hg.mozilla.org/mozilla-central/rev/525a79aa1d44
to 191: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d98e77fa9339

Comment 46

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That looks much better now. Marking as verified fixed with

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090603 Minefield/3.6a1pre ID:20090603031250

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090603 Shiretoko/3.5pre ID:20090603031333