426723 - Awesome bar needs a new throbber so it doesn't look like there is network activity

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

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

Attachment: Awesome bar throbber spec

The current throbber used by the awesome bar is identical to the throbber we use for loading pages, which makes it easy for users to assume that the awesome bar is doing some type of search over the network.

To mitigate this problem I think we should change the visual design of the throbber placed on the site button so that it is not the same as our page load throbber.

So far my favorite idea has been a rotating circle with sections cut out to give the search a subtle "missile lock" feel, for any users who have played a flight simulator, or I guess for the small subset of users who have actually flown a fighter jet.

The circle should be 14x14 with a 2 pixel line width and 2 pixel cuts in the circle (more detailed spec is attached).  Use the following colors for each platform:

OS X: (89,89,89,1)

Windows and Linux:
(0,0,0,0.33) circle
(255,255,255,0.33) gaps

Note: requesting blocking to pick up wanted.

Comment 1

[Justin Dolske [:Dolske]]

Attachment: script for APNG Edit, v.1

This is the script for use in my APNG Edit extension. This renders at 160x160, and should then be scaled down by another script to 16x16.

Linux   = 30% black with 30% white gaps
OS X    = solid rgb(89,89,89) with transparent gaps
Windows = solid black with transparent gaps
Win HC  = solid white with transparent gaps
          (for high-contrast theme, where background is black)

Comment 2

[Justin Dolske [:Dolske]]

Attachment: Linux v.1

Comment 3

[Justin Dolske [:Dolske]]

Attachment: OS X v.1

Comment 4

[Justin Dolske [:Dolske]]

Attachment: Windows v.1

Comment 5

[Justin Dolske [:Dolske]]

Attachment: Windows HC v.1

Comment 6

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

CSS changes to use "loading_16.png".

Comment 7

[Justin Dolske [:Dolske]]

Attachment: Patch v.2

Comment 8

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

Comment on attachment 314049 [details] [diff] [review]
Patch v.2

Should be net-neutral perf hit, and looks pretty cool.

Nice work, Justin & Alex.

Comment 9

[Justin Dolske [:Dolske]]

Checked in. I didn't commit the Windows high-contrast version, since we're not actually making use of that yet. It's here in the bug, though, so when/if that support is added the image is available.

Checking in browser/themes/gnomestripe/browser/browser.css;
  new revision: 1.204; previous revision: 1.203
Checking in browser/themes/gnomestripe/browser/jar.mn;
  new revision: 1.77; previous revision: 1.76
Checking in browser/themes/gnomestripe/browser/places/searching_16.png;
  initial revision: 1.1
Checking in browser/themes/pinstripe/browser/browser.css;
  new revision: 1.139; previous revision: 1.138
Checking in browser/themes/pinstripe/browser/jar.mn;
  new revision: 1.78; previous revision: 1.77
Checking in browser/themes/pinstripe/browser/places/searching_16.png;
  initial revision: 1.1
Checking in browser/themes/winstripe/browser/browser.css;
  new revision: 1.193; previous revision: 1.192
Checking in browser/themes/winstripe/browser/jar.mn;
  new revision: 1.84; previous revision: 1.83
Checking in browser/themes/winstripe/browser/places/searching_16-aero.png;
  initial revision: 1.1
Checking in browser/themes/winstripe/browser/places/searching_16.png;
  initial revision: 1.1

Comment 10

[Dão Gottwald [:dao]]

(In reply to comment #1)
> Win HC  = solid white with transparent gaps
>           (for high-contrast theme, where background is black)

There's a white high-contrast theme.

In general, icons with only a single color can't be used safely. Any reason why -- opposed to comment 0 -- a different icon than on Linux was used?

Comment 11

[Justin Dolske [:Dolske]]

My understanding was that the high-contrast theme would always have a black background here. If that's not true, then the icon certainly needs changed.

In retrospect, the high-contrast design should probably be tweaked anyway, becuase the narrow gaps are probably not terribly visible. Maybe a rotating circle with alternating black/white quadrants (or even thirds). Probably best to handle all this in whatever follow-up bug deals with landing support for high-contrast theme changes.

Comment 12

[Dão Gottwald [:dao]]

(In reply to comment #11)
> My understanding was that the high-contrast theme would always have a black
> background here. If that's not true, then the icon certainly needs changed.

Yes, that's wrong.

Windows is also themable beyond high-contrast settings, so again, why not just use the same icon as on Linux, put any high-contrast thoughts aside? Alex suggested that in comment 0 and I don't see any rationale for why this was changed.

Comment 13

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

When we were working on the icon the implementations for bug 425598 and 426660 were still up in the air.  The rationale for dropping the white marks was that they don't really look great when the throbber is animating, and we figured we could potentially tell the difference between the 4 high contrast themes.  Here is what I think we should do now based on the result of 426660:

(throbber color definitions in comment #1)

OS X: OS X
Windows XP and Vista default theme: Windows
Windows XP and Vista non-default theme: Linux

Comment 14

[Justin Dolske [:Dolske]]

So, it's not clear to me if there are bugs (blocker bugs, at that) covering enabling all that.

Should we go ahead and change the Windows throbber to the Linux one, and let followup bugs handle any other cases?

Comment 15

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

Sure, or reopen and add leverage the functionality of 426660, whichever you prefer.

Comment 16

[Dão Gottwald [:dao]]

(In reply to comment #13)
> The rationale for dropping the white marks was that
> they don't really look great when the throbber is animating

Fwiw, I loaded attachment 314026 [details] in a new tab and switched to it so that the image appears as the favicon, and I don't see the white at all.

Given that bug 426660 is kind of a hack and dbaron wrote that we would likely remove it post-1.9 (in favor of new -moz-appearance and nsLookAndFeel stuff), we should only use it where we currently really need it.

Comment 17

[Dão Gottwald [:dao]]

Justin: ping?

Comment 18

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

(In reply to comment #12)
> Windows is also themable beyond high-contrast settings, so again, why not just
> use the same icon as on Linux, put any high-contrast thoughts aside? Alex
> suggested that in comment 0 and I don't see any rationale for why this was
> changed.

Actually, in that comment he suggested that Windows and Linux both use full black, not that they both use 30% black.

(In reply to comment #16)
> Given that bug 426660 is kind of a hack and dbaron wrote that we would likely
> remove it post-1.9 (in favor of new -moz-appearance and nsLookAndFeel stuff),
> we should only use it where we currently really need it.

This isn't related to this bug, but FTR, that's not really what dbaron said; what he said (and what I agreed with) was that wherever possible, we should be using system generated colours in the UI. His comment about removing it was in reference to a specific example I'd given, where we could eventually pull the colour from nsLookAndFeel.

This throbber isn't something we can regenerate based on colours we pull from the system, it's a fixed image. If we have a version that looks better on the default theme, and another that works for all themes, the attribute from bug 426660 is *precisely* the right thing to be using.

At any rate. The light grey doesn't look that bad to me, although ideally we'd match it up against the colour of the border of the button in which it sits. On Vista that's (160,160,160), or 63% black. Would that be OK on a dark background?

Comment 19

[Dão Gottwald [:dao]]

This isn't about light gray vs. dark gray... I really couldn't care less about that. My point is that comment 0 suggests to use two colors, which would be guaranteed to work with any background. Single-color icons are bad, that's all.

Comment 20

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

Ah, I see, so make the gaps white instead of transparent. I'm with you now. And I agree that I don't see the white in attachment 314026 [details].

Comment 21

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

We don't need the white gaps if we can confirm the os theme is luna or aero.  

>although ideally we'd match it up against the colour of the border
>of the button in which it sits.

Yep, although we can't do detection across the three Luna themes right now, and two of them use a tan color and one of them uses a gray color.

Comment 22

[Dão Gottwald [:dao]]

We don't need to confirm that the OS theme is luna or aero if the white doesn't do any harm.

Comment 23

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

It's hard to describe why the white looks bad it words.  It is kind of like the lines don't line up with their corresponding parts from across the throbber, and the small white lines rotate at an odd and ever changing angle.  It's an anti-aliasing problem due to how small the icon is, and it isn't easy to see, but when you focus on it, it really doesn't look so great.

Comment 24

[Justin Dolske [:Dolske]]

[Mini status update: I'm working on an updated version, but running into a couple of canvas bugs that are giving me some grief.]

Comment 25

[Dão Gottwald [:dao]]

Can the Linux icon be landed in the meantime? As said, I don't want to argue for a particular design, just wanting to make sure that we're in a shippable state without accessibility issues.

Comment 26

[Justin Dolske [:Dolske]]

Ok, finally... :)

http://people.mozilla.com/~dolske/bugs/426723/showcase.html

I generated a few variations (opacity of the black ring / white gap). Beltzner had commented that the Linux version looks too light, talking with Alex the idea was to not make it too dark (to make it not too attention grabbing, and to help it pick up the color tone of the background).

I'd suggest we go with the 75% black / 20% white one, as the new default for Windows and Linux. Beltzner, you want to make the final call here? (Other comments welcome, of course.)

Comment 27

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

Let's do 66/30. a=beltzner

Comment 28

[Justin Dolske [:Dolske]]

Checked in.

Checking in browser/themes/gnomestripe/browser/places/searching_16.png;
  new revision: 1.2; previous revision: 1.1
Checking in browser/themes/winstripe/browser/places/searching_16-aero.png;
  new revision: 1.2; previous revision: 1.1
Checking in browser/themes/winstripe/browser/places/searching_16.png;
  new revision: 1.2; previous revision: 1.1

Comment 29

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

I wanted to verify these changes but got trouble in seeing this throbber at all on Windows. What requirements my places data must have so that the throbber is shown?

Comment 30

[Ed Lee :Mardak]

Have enough pages in your history so that it needs to multiple searches.. you can set this pref to something smaller like 15:

browser.urlbar.search.chunkSize

Then search for "awjflawkjelfkwje" that won't match anything.

Comment 31

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

Ok, that made it. Thanks. Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008050104 Minefield/3.0pre ID:2008050104 and the appropriate Windows build.