Closed
Bug 426723
Opened 17 years ago
Closed 17 years ago
Awesome bar needs a new throbber so it doesn't look like there is network activity
Categories
(Firefox :: Theme, defect)
Firefox
Theme
Tracking
()
VERIFIED
FIXED
Firefox 3
People
(Reporter: faaborg, Assigned: Dolske)
References
Details
Attachments
(7 files, 1 obsolete file)
(deleted),
image/png
|
Details | |
(deleted),
application/x-javascript
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
beltzner
:
review+
beltzner
:
ui-review+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
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.
Flags: blocking-firefox3?
Assignee | ||
Comment 1•17 years ago
|
||
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)
Assignee | ||
Comment 2•17 years ago
|
||
Assignee | ||
Comment 3•17 years ago
|
||
Assignee | ||
Comment 4•17 years ago
|
||
Assignee | ||
Comment 5•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Attachment #314025 -
Attachment description: script for APNG Edit → script for APNG Edit, v.1
Assignee | ||
Comment 6•17 years ago
|
||
CSS changes to use "loading_16.png".
Attachment #314039 -
Flags: ui-review?(beltzner)
Attachment #314039 -
Flags: review?(beltzner)
Assignee | ||
Comment 7•17 years ago
|
||
Attachment #314039 -
Attachment is obsolete: true
Attachment #314049 -
Flags: ui-review?(beltzner)
Attachment #314049 -
Flags: review?(beltzner)
Attachment #314039 -
Flags: ui-review?(beltzner)
Attachment #314039 -
Flags: review?(beltzner)
Updated•17 years ago
|
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
Comment 8•17 years ago
|
||
Comment on attachment 314049 [details] [diff] [review]
Patch v.2
Should be net-neutral perf hit, and looks pretty cool.
Nice work, Justin & Alex.
Attachment #314049 -
Flags: ui-review?(beltzner)
Attachment #314049 -
Flags: ui-review+
Attachment #314049 -
Flags: review?(beltzner)
Attachment #314049 -
Flags: review+
Attachment #314049 -
Flags: approval1.9+
Assignee | ||
Comment 9•17 years ago
|
||
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
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3
Comment 10•17 years ago
|
||
(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?
Assignee | ||
Comment 11•17 years ago
|
||
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•17 years ago
|
||
(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.
Reporter | ||
Comment 13•17 years ago
|
||
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
Assignee | ||
Comment 14•17 years ago
|
||
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?
Reporter | ||
Comment 15•17 years ago
|
||
Sure, or reopen and add leverage the functionality of 426660, whichever you prefer.
Comment 16•17 years ago
|
||
(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•17 years ago
|
||
Justin: ping?
Comment 18•17 years ago
|
||
(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•17 years ago
|
||
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•17 years ago
|
||
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].
Reporter | ||
Comment 21•17 years ago
|
||
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•17 years ago
|
||
We don't need to confirm that the OS theme is luna or aero if the white doesn't do any harm.
Reporter | ||
Comment 23•17 years ago
|
||
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.
Updated•17 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 24•17 years ago
|
||
[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•17 years ago
|
||
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.
Assignee | ||
Comment 26•17 years ago
|
||
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•17 years ago
|
||
Let's do 66/30. a=beltzner
Assignee | ||
Comment 28•17 years ago
|
||
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
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Comment 29•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
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.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•