Closed Bug 423744 Opened 16 years ago Closed 3 years ago

use platform-compatible styling for notification bars (luna, aero)

Categories

(Toolkit :: Themes, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: madhava, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: polish, uiwanted, Whiteboard: [polish-easy][polish-visual])

Attachments

(6 files, 3 obsolete files)

The current notification bar colors don't fit with the XP platform colors.

Suggestions for revised coloring to come.
Attached image colour suggestions
We're using InfoBackground. That's the correct platform color.
Moving my blocking request from bug 425116 for inappropriately using a question mark icon for notifications.
Flags: blocking-firefox3?
Not going to block, would take a patch to use these.
Flags: blocking-firefox3? → blocking-firefox3-
Had a look at this just now at beltzner's behest.  It's a pretty simple change, but backgrounds don't work the way they are described here.

CSS doesn't provide for background stretching.  If you look at, e.g., the site button under Large Fonts, you'll see that the gradient in the button is not stretched, but instead just shifted up to the top half of the element.  Because the background only repeats horizontally, and because the background colour of the element matches the bottom of the gradient, this degrades pretty gracefully.  If I try to use the 60px gradients here, though, then for normal (30px) users, the bottom of the gradient is clipped.

One final impediment here is that the gradients here in XP, and in bug 423742 for Vista, both have darkened footer lines.  This means that we can't just "degrade gracefully" into a solid background colour, since the footer line at the bottom of the actual graphic would be evident for users with large fonts.

What we probably want to do is:

 - replace the graphics with regular-height versions
   - without footer darkening
 - write the CSS to use those graphics
   - repeating horizontally, and attached to the top of the bar
   - and fail down to a color that matches the bottom of the gradient
 - and add CSS for the footer line, probably using a CSS border directive.

All of this is ditto for bug 423742, but I don't really want to type it twice.  I suspect these will be fixed together anyhow.
In terms of the structure of the change (in case someone gets to this before me), you basically want to just update notification.css in toolkit/themes/winstripe/global with a bunch of changes that look like this:

 notification[type="critical"] {
-  background-color: red;
+  background: url("chrome://global/skin/icons/errorBar-30.png") #BB0000 top repeat-x;
   color: white;
 }

where errorBar-30.png is the (hypothetical) normal height gradient fill appropriate to the severity level, and #BB0000 is the rgb code for the colour at the bottom of that gradient.

If we get new gradient files (and while we're at it, preferred colours/weights for footer borders and foreground text) I can toss this patch together, but beltzner was making noises like maybe he would do it while in MV, and sitting within speaking distance of Alex.  :)

For Vista, things are basically exactly the same, except you'll also have to clone notification.css into notification-aero.css as described in bug 420232 comment 4.  Include all the regular notification.css stuff, and then re-define whatever vista-specific rules are needed.
(In reply to comment #8)
>  - write the CSS to use those graphics
>    - repeating horizontally, and attached to the top of the bar

The image doesn't have to be attached to the top, it can also be centered.
Btw, it's kind of unfortunate that images that won't work as intended have been checked in *and* added to jar.mn. Do the right people keep track of that, so that images that remain unused won't be shipped?
Ok, I'll get us new images and make sure we don't ship any of the incorrect ones.
(In reply to comment #11)
> Btw, it's kind of unfortunate that images that won't work as intended have been
> checked in *and* added to jar.mn. Do the right people keep track of that, so
> that images that remain unused won't be shipped?

Yes, Phil and Alex have both been doing that, and I trust Alex to take things out of jar.mn if we don't use them, though we can make sure we do another review. We've taken out a bunch of the Places stuff recently, AIUI.

In this case we put the images in there on the understanding that it was the most expedient way of getting this bug fixed. There's no real theme owner, so we're trying to be as agile as possible. It's my fault for not understanding how the gradient images work, and my fault for having these generated to the wrong specifications to begin with - apologies tendered, but there's no real documentation on how this works, and it's hard to find the right people on IRC to ask.
New background images for the notification bars will land with bug bug 430759
Requesting blocking since we have all the files and this impacts the UI of the main window.
Flags: blocking-firefox3- → blocking-firefox3?
What's changed other than having the images?  If we get a fix, great, but it wasn't a blocker six days ago, so why would it be a blocker now?
Flags: blocking-firefox3? → blocking-firefox3-
I've tried to take this bug repeatedly, but I can't. Here's why:

Comment 0 claims that "The current notification bar colors don't fit with the XP platform colors." That's not backed up by anything. We are using platform colors and they do feel native to me.

To address this bug as proposed, we'd have to stop using InfoBackground, -moz-dialog and the corresponding text colors. This would go against a certain principle:

  "We should [..] minimize the amount of truly hardcoded colors we're using,
  and use native colors as a general rule."
  --Mike Connor, bug 425598 comment 20

  "wherever possible, we *will* continue to use system colours which react
  based on the user selected theme."
  --Mike Beltzner, bug 426660 comment 26

We couldn't even use the windows-default-theme thingy, because informationBarIcon-16.png & Co. aren't designed to work on arbitrary backgrounds.

To proceed the correct way, we'd need to:
1. get transparent questionBar and informationBar images that can be used on top of native backgrounds.
2. get icons that will be visible on any background.
Attachment #318081 - Attachment description: simple gradient → simple gradient on native colors
Attachment #318081 - Flags: ui-review?(beltzner)
>We are using platform colors and they do feel native to me.

You're correct that InfoBackground is a platform color.  I didn't realize that, but the shade of blue for the level of notifications used by the password manager is (was?) I believe arbitrarily selected.  The other issue is that we want these to feel like chrome and not content, and we believe giving them a chrome style texture is the best way to achieve that.

>1. get transparent questionBar and informationBar images that can be used on
>top of native backgrounds.
>2. get icons that will be visible on any background.

We want the notification bars to match the style of dialog common dialog icons on each platform, which is why we had the iconfactory go through multiple revisions of 16 different files for this change.

Here is what I propose
-Default theme: use a background gradient and icon out of the set we had produced specifically for these bars
-Not the Default theme: use system colors for the background and text, and 16x16 common dialog icons that are designed to work on any background color.

Special icons (popups blocked, password manager key, etc) should work on the range of backgrounds being considered.
I think I got all of the bars with special icons in here as well, but let me know if I forgot anything.
Looks like I forgot to switch the question and info backgrounds to moz-dialog(?) for the non-default bars in the mockup.
(In reply to comment #21)
> >We are using platform colors and they do feel native to me.
> 
> You're correct that InfoBackground is a platform color.  I didn't realize that,
> but the shade of blue for the level of notifications used by the password
> manager is (was?) I believe arbitrarily selected.  The other issue is that we
> want these to feel like chrome and not content, and we believe giving them a
> chrome style texture is the best way to achieve that.

The password notification is using -moz-dialog, which is probably the most common chrome color. The tab bar uses the same color on XP (see attachment 318081 [details]), so it definitely feels integrated there.
Why do you think the blue that you've selected would feel more like chrome? Looks pretty non-standard to me as an XP user. (I could say the same about the yellow, although that's at least slightly closer to InfoBackground.)

> Here is what I propose
> -Default theme: use a background gradient and icon out of the set we had
> produced specifically for these bars
> -Not the Default theme: use system colors for the background and text, and
> 16x16 common dialog icons that are designed to work on any background color.

We can't change the icons depending on the OS theme.
So, as I understand it, this bug can be split into two phases:

Phase 1: Use the existing backgrounds, but add default icons from the right column of attachment 318199 [details]. These icons should still look reasonable, even when the native-theme uses arbitrary colors that end up as the notification bar background.

Phase 2: Use the new CSS selectors to implement the left column of attachment 318199 [details]. So, when you're using the default theme we use new background colors/images and icons as shown there. If you're not using the default theme, you'd see no change from Phase 1.

Mixed in with this is fixing some or all of bug 415400, so that CSS can control what icon is displayed.
Yes, except that I still disagree with the new background color approach in phase 2, where "XP platform colors" means less native and less integrated in my view.

I think Alex was referring to Vista when he wrote "the shade of blue for the level of notifications used by the password manager is (was?) I believe arbitrarily selected." I will say that the color (-moz-dialog) makes perfectly sense for this, but let's assume it looks bad on Vista. What's the problem on XP that we're trying to solve?
>What's the problem on XP that we're trying to solve?

We want clearly noticeable notifications that look luna-y (or in the case of Vista, aeroish).
Depends on: 415400
Blocks: 431077
(In reply to comment #25)
> So, as I understand it, this bug can be split into two phases:

Alex noted that we could also take a different route... Skip doing any icon changes (for now), and use -moz-system-metric(windows-default-theme) to change the look of notification bars for the default theme. This gives us most of the visual splash, without having to deal with all the existing notification box icons.
Attached file close sidebar buttons.zip (obsolete) —
These are the new close sidebar buttons

blue background, red background: closeSidebarWhite
default background, yellow background: closeSidebar
(In reply to comment #27)
> >What's the problem on XP that we're trying to solve?
> 
> We want clearly noticeable notifications that look luna-y (or in the case of
> Vista, aeroish).

I know your intentions. They are good.
I don't get why somebody would consider the current style as not integrated, or as a failure in terms of "feel like chrome and not content". As I said, we're using the same color as for the XP tab bar and basically all other dialogs. Where's the shade of blue that you were referring to?
I don't get why the blue is expected to look more like chrome. It's not used anywhere else for chrome.
Attached patch Patch v.1 (obsolete) — Splinter Review
Taking a shot at Alex's suggestion: uses the new backgrounds with the existing icons, only when using the default Windows theme. The background color here (only seen if large fonts are in play) is from the top pixel color of the XP icons. Used the min-height from Dao's patch to help ensure a bit of padding around the bar's buttons (not sure if "29" is a magic number or if it was calculated from something?).
Attachment #318339 - Flags: ui-review?(beltzner)
Attachment #318339 - Flags: review?(beltzner)
Comment on attachment 318323 [details]
close sidebar buttons.zip

[AFAIK these need ui-r or at least a1.9 to land. Not yet used in this patch.]
Attachment #318323 - Flags: ui-review?(beltzner)
>Where's the shade of blue that you were referring to?

I believe it was the default color for the information level of notification
before it got changed to -moz-dialog on windows.  There is nothing really wrong
with the current styling on windows (unlike for instance the styling on OS X
before it was updated).

>I don't get why the blue is expected to look more like chrome. It's not used
>anywhere else for chrome.

Well for the default windows theme the shade somewhat references the window
border, task bar, and start menu, in addition to the standard information
icons.  However the color isn't the part that we wanted to leverage to make it
more chrome like, the texture is.  For instance, I think
https://bugzilla.mozilla.org/attachment.cgi?id=318081 looks more like chrome
than the flat system colors.

OK, so I think matching the color of the tab bar or other dialogs is more important than matching the color of the task bar (blue Luna only, mind you), especially when it comes to looking like chrome. Anyway, seems like we don't have to argue about the color any further.

We have a common ground with the texture. I can see that as a straight improvement. Therefore I renew my proposal to use a transparent texture with the current native colors, regardless of the OS theme. If attachment 318081 [details] isn't quite there yet, I could tweak it without much effort.

Justin: 29 is, I think, the height of current notifications with buttons. I added it as a min-height to make sure that notifications without buttons (e.g. malware) aren't squeezed.
>Justin: 29 is, I think, the height of current notifications with buttons.

Let's use a min height of 30 so we pick up the 3 pixel bevel at the bottom of the images.

In terms of the colors vs. moz-dialog, by leveraging the colors used in dialog icons we get colors that are already semantically loaded for the type of bar, and the bars are also a little more noticeable.
(In reply to comment #36)
> >Justin: 29 is, I think, the height of current notifications with buttons.
> 
> Let's use a min height of 30 so we pick up the 3 pixel bevel at the bottom of
> the images.

The images are already attached to the bottom of the bar.

> In terms of the colors vs. moz-dialog, by leveraging the colors used in dialog
> icons we get colors that are already semantically loaded for the type of bar,
> and the bars are also a little more noticeable.

I don't think there's anything wrong with the color of the icons in the right side of attachment 318199 [details] combined with -moz-dialog / InfoBackground. In fact, they will be more visible there.
The right side looks jarring to me ("a little more noticeable"? :)), and the icons fade away as expected.
I think that to argue this point from the "XP color palette" perspective is flawed, because there isn't a XP color palette.  Luna has three palettes: Blue, Olive, and Silver.  And let's not forget that all the Media Center users (basically anyone who buys a consumer-brand PC) will be using Royale.  I agree with Dao: if a native look is what we're after, the status-quo is pretty good.

That having been said, I think that there's still an argument to be made for changing the styling, but for semantics, not nativeness.  If the goal is to convey a certain message to the user, then using neutral UI colors may not be a good idea.

FWIW, InfoBackground is not guaranteed to be yellow--it isn't on Vista, and I used to run my system with a white InfoBackground.  I think that semantics is a case where some hard-coding of colors could be a good idea.  Hard-code yellow for warnings (even non Classic and non-default; I don't really see why we shouldn't make the semantic distinction for those systems), hard-code red for errors, and use the neutral native dialog color for questions and info.  As for the actual implementation, I think that Dao's method of just applying a simple gradient is best.  The right side of attachment 318374 [details] looks a little... um... flamboyant.
(In reply to comment #39)
> FWIW, InfoBackground is not guaranteed to be yellow--it isn't on Vista, and I
> used to run my system with a white InfoBackground.  I think that semantics is a
> case where some hard-coding of colors could be a good idea.  Hard-code yellow
> for warnings (even non Classic and non-default; I don't really see why we
> shouldn't make the semantic distinction for those systems), hard-code red for
> errors, and use the neutral native dialog color for questions and info.

It appears to me that the notifications' type attribute is a little bit flawed... the "popup blocked" notification isn't really a "warning" in my view, it's neutral information most of the time. The "save password?" notification, on the other hand, isn't "info", it's a non-modal dialog. Therefore I think InfoBackground and -moz-dialog make quite some sense for what notification.xml or its consumers consider a "warning" or "info".
(In reply to comment #40)
> It appears to me that the notifications' type attribute is a little bit
> flawed... the "popup blocked" notification isn't really a "warning" in my view,
> it's neutral information most of the time. The "save password?" notification,
> on the other hand, isn't "info", it's a non-modal dialog. Therefore I think
> InfoBackground and -moz-dialog make quite some sense for what notification.xml
> or its consumers consider a "warning" or "info".
> 

Good point.  How about 4 states, then?
* Neutral dialog: native dialog color (e.g., password)
* Neutral notice: native tooltip color (e.g., popup and installation, or should installations be classified as a dialog?)
* Warnings: hard-code yellow
* Error, phishing, malware: hard-code red
I don't think adding another notification bar state is an option at this point, that ends up touching a fair chunk of code, in ways deeper than just style changes.

Long term, I think that's probably a good idea (even independently of how the bars are styled). It seems like some "information" notification bars are being used in ways that are really more question-like. I suspect Alex has noticed this too, since there's additional "question-16.png" and "questionBar-30.png" artwork in addition to the 3 types (info/warning/error) being discussed here.

But that should wait until the next release. The question here is how to style the 3 notification bars as they exist today.
I've previously wanted us to move popups blocked from a warning level to an information level, but beltzner pointed out (and I think I agree with him now) that the browser is changing the behavior of the site, and actively blocking something the site wanted to show you, so it is important that the notification is clearly noticeable.  It still feels a little stressful when popups are blocked though.

There is no color palette for chrome on XP (with blue, silver and olive) but there is a very specific color palette for graphics.  These bars are a little odd in that we are taking a system dialog box icon, and kind of stretching it across chrome.

I think warning needs to be yellow and error red.  I'll put together some mockups of the blue on on the three luna themes + royale and zune so we can take a look at how it fits across the set of possible default themes.
Here are mockups of the various bars on:

-XP Classic
-XP Luna Blue
-XP Luna Silver
-XP Luna Olive
-XP Royale
-XP Zune

-Vista Aero
-Vista Classic

http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarXP.png
http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarVista.png

Beltzner: can you ui-r this so we can get the refresh landed.  We need to decide if the icon palette works well enough on the various range of themes, and what style we want for the information level bar (blue or -moz-dialog).
(In reply to comment #44)
> Here are mockups of the various bars on:

> http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarXP.png
> http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarVista.png
> 
> Beltzner: can you ui-r this so we can get the refresh landed.  We need to
> decide if the icon palette works well enough on the various range of themes,
> and what style we want for the information level bar (blue or -moz-dialog).

And if InfoBackground makes sense for critical notifications (I don't think it does), and whether to use a texture for the native colors (I think we should).
What should we use for critical notifications (as a side question do we actually have any critical notifications?)  Example of texture on native colors is https://bugzilla.mozilla.org/attachment.cgi?id=318081
The malware notification (http://www.mozilla.com/firefox/its-an-attack.html) is critical, and I think it should be red. This is something that really should stand out and where we don't have a native color.
(In reply to comment #43)
> I've previously wanted us to move popups blocked from a warning level to an
> information level, but beltzner pointed out (and I think I agree with him now)
> that the browser is changing the behavior of the site, and actively blocking
> something the site wanted to show you, so it is important that the notification
> is clearly noticeable.  It still feels a little stressful when popups are
> blocked though.

Note that even if we consider "popup blocked" a warning, InfoBackground continues to work in that a warning is some kind of an information. The yelling yellow makes only sense if we're 100% sure that this notification and all others that are currently using that style are strong warnings that should steal the user's attention every time, no matter what, even if he already knows and really doesn't care. (The same notifications appear repeatedly as users revisit sites, repeat actions, etc.)
"Restart Firefox to complete your changes" is another "warning"-level notification which currently makes sense only because we use InfoBackground.
Alex and I spoke about this a bit yesterday, and both agreed that the gradient on native colours actually works better. Alex has some ideas about what the gradient itself should look like (Alex, can you please comment?) and if he and Dao can work it out, we should go with that approach.
Comment on attachment 318081 [details]
simple gradient on native colors

This is the right approach, but please sync up with Alex on tweaking the gradient that we use.
Attachment #318081 - Flags: ui-review?(beltzner) → ui-review+
(In reply to comment #49)
> "Restart Firefox to complete your changes" is another "warning"-level
> notification which currently makes sense only because we use InfoBackground.

Sure - we picked the yellow because we wanted it to be noticed. On OSX the yellow is really brilliant as well, and the result isn't that bad, but I think only because OSX tends to use saturated colours.

As you and Alex point out, the dark saturated colours on XP and Vista don't look quite right. We should use a combination of the gradient and more muted colours to achieve success.
>Alex has some ideas about what the
>gradient itself should look like (Alex, can you please comment?)

I'll put some examples together of what I was thinking of, basically I want to overlay a gradient that matches the bevel of the lowest toolbar on Luna, and (maybe if it looks ok) the glassy bar appearance on aero.   I don't think we should be using any form of gradients for classic (in both this and other interfaces).
There's a big precedent for a similar gradient in the tab bar, which I think doesn't look too alien on Classic. The downside of not using a gradient for Classic is that we wouldn't use it for third-party themes too.
[note: I have no idea if we are totally frozen or not yet, but I'm still continuing to work on this until I hear we are not taking any more changes]

I spent quite a bit of time playing around with gradients to overlay -moz-dialog and InfoBackground, and I couldn't find anything I was really happy with.

Thinking about the whole idea of these notification bars more, I think we should try to create an interface that users can process with their peripheral vision.  The only two ways I can think of doing this are:

-Use a large image (the plan for notification redesign for Firefox 3.1 that got cut from Firefox 3)
-use a color that carries semantic meaning

Here is a pretty rough mockup of what I am talking about:

http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarAmbient.png

It's a little counter intuitive, because we are evaluating these various designs by looking directly at them, but I want to create a design that conveys information when you are looking away.  

I'm not sure that I buy into the colors we are considering not appearing native since we are only considering using them for the set of default themes.  The default themes (with the exception of Zune) us a pretty predictable color palette.  I do however agree that the recent proposal was way to saturated.  I tried lightening the images, although I'm not incredibly happy with the result:

http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarVistaLighten.png

http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarXPLighten.png

One idea that could be pretty cool (but is potentially impossible to implement or way out of scope) is if we used the page's background color behind the partially transparent notification bar.  We would still want to slide the page down like we currently do, but this would give a sense of the bar overlaying the page, and on Vista would give it even more of a glassy feel.

I'm going to keep working on some mockups to see if we can get something that:
-looks native
-doesn't blend into the toolbar
-conveys information ambiently
-isn't too saturated

worse case scenario we'll just keep things the same, or drop is some very minor gradients.
(In reply to comment #55)
> Here is a pretty rough mockup of what I am talking about:
> 
> http://people.mozilla.com/~faaborg/files/granParadisoUI/notificationBarAmbient.png

What a still image can't show is that the notification bars slide in and push the whole page, which is quite noticeable.

> It's a little counter intuitive, because we are evaluating these various
> designs by looking directly at them, but I want to create a design that conveys
> information when you are looking away.

Well, that's only part of what I'd call a good UI, and it kind of reminds me of modal dialogs. Another goal should be to be unobtrusive, so that the user can move on and doesn't feel compelled to react.
>What a still image can't show is that the notification bars slide in and push
>the whole page, which is quite noticeable.

Right, I'm not saying that they are not noticeable, I'm saying that the -moz-dialog doesn't convey any meaning.  Over time users could potentially learn that blue = password manager, so that they will be able to both notice and know what the bar is saying without having to directly look at it.

>Another goal should be to be unobtrusive, so that the user can
>move on and doesn't feel compelled to react.

yep, which is why I agree the saturated colors aren't working very well.
(In reply to comment #57)
> Right, I'm not saying that they are not noticeable, I'm saying that the
> -moz-dialog doesn't convey any meaning.

It's the chrome color that's usually used for dialogs. As such it works, but I can see how it doesn't fit your idea.

> Over time users could potentially
> learn that blue = password manager, so that they will be able to both notice
> and know what the bar is saying without having to directly look at it.

... which could be counter-productive if we add another notification of that type. If users really learn the way you say, we would either confuse them by abusing the well-known color or by introducing a new one. I'd rather have them learn "bar that appears after logging in = password manager".
>which could be counter-productive if we add another notification of that
>type.

After this release we will likely switch to using the door hanger style notifications off of the site button which will convey meaning peripherally through large icons, so we probably don't need to worry about overloading the color in the long run.

>I'd rather have them learn "bar that appears after logging in = password
>manager".

Yeah, they should pick up on that up as well either way.
(In reply to comment #59)
> >which could be counter-productive if we add another notification of that
> >type.
> 
> After this release we will likely switch to using the door hanger style
> notifications off of the site button which will convey meaning peripherally
> through large icons, so we probably don't need to worry about overloading the
> color in the long run.

I think that's a failure in terms of unobtrusiveness (it's impossible to ignore something that overlays the page), but that's a different discussion ...
Keywords: polish
Keywords: polish
Blocks: 434153
Summary: use XP platform-compatible styling for notification bars → use platform-compatible styling for notification bars (luna, aero)
Let's go for the gradients over extracted system colors approach and try to get this landed. this bug is eligible for bug 462081 :)
Keywords: polish
Whiteboard: [polish-easy][polish-visual]
Whiteboard: [polish-easy][polish-visual] → [polish-easy][polish-visual][polish-high-visibility]
Assignee: nobody → dao
Attachment #318108 - Attachment is obsolete: true
Attachment #318323 - Attachment is obsolete: true
Attachment #318339 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #345277 - Flags: review?(rflint)
Attachment #318339 - Flags: ui-review?(beltzner)
Attachment #318339 - Flags: review?(beltzner)
Attachment #318323 - Flags: ui-review?(beltzner)
uiwanted: new mockups
Keywords: uiwanted
Also, red bar is now being used for plugin blocklisting, so we need to actually consider its appearance this time.
Assignee: dao → nobody
Status: ASSIGNED → NEW
Red's already in use for users who click through phishing/malware warnings as of FF3, in fact.
Right, but it hasn't been themed yet on Windows or Linux (I'm assuming that the current appearance was meant to be temporary).  The OS X bar looks great.
(In reply to comment #66)
> Right, but it hasn't been themed yet on Windows or Linux (I'm assuming that the
> current appearance was meant to be temporary).

Clearly.  :)
Comment on attachment 345277 [details] [diff] [review]
patch: simple gradient on native colors (updated)

(In reply to comment #64)
> Also, red bar is now being used for plugin blocklisting, so we need to actually
> consider its appearance this time.

This patch actually changes the color for critical bars from red to rgb(166, 24, 0).

But given comment 61 and comment 63, it's not clear to me whether this patch is wanted.
Attachment #345277 - Flags: review?(rflint)
Invalidating in favor of a new notification UI for Firefox.next that is currently being worked on by dolske and Matthew Noorenberghe at an API level.  I'll be posting initial UI mockups to dev.apps.firefox soon.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Whiteboard: [polish-easy][polish-visual][polish-high-visibility] → [polish-easy][polish-visual]
As far as I can tell, the notification bars aren't going away, e.g. in the add-ons manager.
Status: RESOLVED → REOPENED
Component: Theme → Themes
Flags: blocking-firefox3-
Product: Firefox → Toolkit
QA Contact: theme → themes
Resolution: INVALID → ---
Status: REOPENED → NEW
No longer depends on: 425598
Status: NEW → RESOLVED
Closed: 15 years ago3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: