354940 - Make background color in URL bar for https: more obvious

Status: RESOLVED FIXED

(SeaMonkey :: Themes, defect)

Description

[Frank Wein [:mcsmurf]]

Currently the color for the background in the URL bar is not very obvious when visiting a https:// site. It more looks like dark white or white with a tiny bit of yellow in it, at least with bright displays. I heard the tooltip color is used for this, maybe another color should be used for it.

Comment 1

[Frank Wein [:mcsmurf]]

Attachment: Comparison of SeaMonkey and Firefox

This screenshot compares the background colors of SeaMonkey and Firefox (Minefield), the FF one is (a lot) more obvious.

Comment 2

[Felix Miata]

Lack of that ugly yellow is one of the SM advantages over other browsers. I've turned that yellow off entirely through CSS. It ought to be easy for those who don't know CSS to do the same. IOW, there should be a UI for setting a color of choice for HTTPS pages, or moving the padlock from the status bar to the urlbar.

Comment 3

[Cédric "chewey" Menge]

The current colour doesn't make too much sense for multiple reasons: It indeed is too bright, making it difficult to distinguish from its non-SSL counterpart, especially on poorly calibrated displays (= most of them).
Additionally, it isn't intuitive at all: What is a yellow URL bar supposed to mean? That is why I have CSSed that colour to a light green (#C5FAC5) on all SM installations I maintain.

I'd recommend changing the default colour for SSL sites to something comparable.

Comment 4

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 5

[rsx11m]

This issue was actually mentioned in today's status meeting, thus it should be worth reviving this bug report.

Indeed, with the Windows Classic theme I get something like #ffffe1 [rgb(255,255,225)] whereas #ffffcc [rgb(255,255,204)] seems to be the right shade.

Changing platform to "All" given that the dependencies are even worse on Linux. If you pick a desktop theme which has a color other than yellow for the tooltips, indeed that color is used to "highlight" the secure site, thus turning the background blue or gray (or whatever the tooltip color of that theme happens to be).

The modern theme has #e8db99 [rgb(232,219,153)] hardwired, thus fitting the darker chrome background for this theme. Consequently, only the classic theme should need some adjustment, possibly introducing hardwired colors for this special case as well (we have them elsewhere, e.g., in the secure-connection box for verified certificates with ownership information).

Comment 6

[rsx11m]

Attachment: Comparison of different shades

I've made a little comparison sheet with different shades of yellow (assuming that we'll stick with that color in general to highlight secure sites).

The top shows the current classic and modern colors (with classic using the Windows 7 default theme, but it's the same on the Windows Classic desktop).

The second row shows a 25%-saturated #ffffcc yellow next to the estimated Firefox 2.0 shade shown in attachment 240720 [details] (which had a gradient, thus it's kind of averaged along its height).

The last row shows a more saturated #ffffb0 yellow, which is nicely bright and should do the job, and a half-way compromise between the yellow shades and the Firefox 2.0 appearance with #f9fab9 in the lower right corners. I'd probably pick one of those.

Any opinions?

Stefan, seeing that you've added yourself to the CC list, how about Mac?

Comment 7

[rsx11m]

Attachment: Mockup screenshots

These are simple userChrome.css rules for .urlbar-security-level[level="high"] applied to the latest aurora nightly build, to get some quick impression how those colors look like in the actual urlbar context.

The top pair shows Windows 7 Aero default and Windows 7 Classic desktop themes with the current #ffffe1 background color for comparison.

The center pair shows #ffffb0 which looks to me a bit too intense and conveys more the impression of a warning than something that you'd like to want.

The bottom pair with the #f9fab9 half-way color is a bit darker and less saturated, looks best to me (at least on this screen).

Comment 8

[Stefan [:stefanh]]

(In reply to rsx11m from comment #6)
> Stefan, seeing that you've added yourself to the CC list, how about Mac?

I'm watching the component, but I sometimes CC myself on interesting bugs :-) I'll try to take a look and see how your suggestions look on Mac (but, as usual, I'll be a bit slow).

Comment 9

[rsx11m]

No hurry, we've just started a new release cycle. ;-)

I'll post a patch for easier testing late tomorrow, with the changes I'd see necessary in the Mac version of navigator.css but which I can't test.

(In reply to Felix Miata from comment #2)
> I've turned that yellow off entirely through CSS. It ought to be easy for
> those who don't know CSS to do the same.

Well, emphasizing secure sites is done via the themes, thus not tied to any preference. Adding a customizable color through a pref seems to be tough as there would need to be a -moz-* color defined in CSS which depends on it. Some boolean pref might be easier and could be evaluated in nsBrowserStatusHandler.js when setting the security level in the onSecurityChange() function, but would imply a bit of overhead and yet another browser.urlbar.* pref.

Comment 10

[rsx11m]

Attachment: Linux screenshots

Here is a comparison of screenshots taken before and after changing the color on Linux (patch follows) with a rather grayish desktop theme on KDE4. Consequently, the "https://" color is gray here given that the tooltip background is gray.

Note that I've also changed the padlock/security box to match the color. While the location bar looks fine to me, I'm not sure if I like that color in the security box where the current (modern-style) color is better visible (and there is a fairly large distance between the location bar and the box, the latter also coming in other colors like green for verified organization names).

Comment 11

[rsx11m]

(In reply to Cédric "chewey" Menge from comment #3)
> indeed is too bright, making it difficult to distinguish from its non-SSL
> counterpart, especially on poorly calibrated displays (= most of them).

That's a good point. I've noticed that it also depends on the viewing angle. Thus, with the proposed patch, it looks just right when looking straight at the monitor, but gets pale when I tilt it to look from the top. Conversely, tilting it so that I look at it from a bottom angle causes the color to be more intense. Thus, it would be hard to find a color that's right for all conditions.

(In reply to Felix Miata from comment #2)
> or moving the padlock from the status bar to the urlbar.

That's what Firefox eventually did. I don't like it given that if your browser window is narrow and the name of the organization wide, you are loosing a lot of real estate on the screen. Also, Firefox ended up removing the status bar entirely, thus the current arrangement makes sense for them from this angle as well.

Comment 12

[rsx11m]

Attachment: Patch for #F9FAB9

Here comes the patch for changing the secure-connection background color for both the location bar and the security box. Note that I also had to change the font color from InfoText to black, thus to avoid that it disappears if the desktop theme's tooltip font color happens to be a bright one.

Comment 13

[rsx11m]

Attachment: Patch with on/off preference

(In reply to rsx11m from comment #9)
> Some boolean pref might be easier and could be evaluated in
> nsBrowserStatusHandler.js when setting the security level in the
> onSecurityChange() function, but would imply a bit of overhead and yet
> another browser.urlbar.* pref.

That was actually fairly straightforward to implement. This patch adds a hidden preference browser.urlbar.highlight.secure to toggle the special background color for secure connection. This is achieved by simply not setting the "level" attribute if that preference is false.

If we want to go with that preference, it would be easy to add a checkbox to the Location Bar prefpane (probably in a follow-up bug, different component).

In contrast, introducing a color preference would likely involve a Core change (style/) to define new -moz-secure-level-high/broken CSS color values, thus I'm not going to follow that path.

This patch also keeps the #E8DB99 color for the security box in the status bar intact.

Note that the mac/ part isn't tested in either patch per comment #9.

Comment 14

[rsx11m]

(In reply to rsx11m from comment #6)
> Firefox 2.0 shade shown in attachment 240720 [details] (which had a
> gradient, thus it's kind of averaged along its height).

For reference: I've looked up the browser.css code for FF 2.0.0.x, and it says #F5F6BE for the background (with #F7F898 commented out). Thus, you can try either of those as well. Firefox also had a hard-wired #000000 for the font color, so the patch is on par here.

Comment 15

[Stefan [:stefanh]]

Attachment: Mac OSX Screenshots

I did some screenshots comparing the proposed color with the current and what Firefox 2.0 had (FFFED8). As you can see, the current color is much better than the color Firefox 2.0 had. I don't see any problem with the current color we have for Mac. I suppose you could say that the proposed color is a bit "stronger", but otoh I think the current color for mac looks better :-)

I don't mind changing the color, but I think the proposed color has a bit too much green in it to suit my taste (I would actually prefer moving the padlock to the url bar, but that's another discussion).

The Mac infobackground color is actually hardcosed in nsLookAndFeel.mm:
209     case eColorID_infobackground:
210       aColor = NS_RGB(0xFF,0xFF,0xC7);
211       break;

How does FFFFC7 looks like on win/nix?

Comment 16

[rsx11m]

Attachment: Windows Classic, with #FFF5B4

The #FFFFC7 comes close to the #FFFFCC shade shown in attachment 824213 [details] and brings it a tad closer to the #FFFFB0 shade which I figured was a bit too intense.

And yes, #F9FAB9 has a bit of green in it, but that's close to the hue the Firefox 2 theme had than a clean yellow. Since comment #3 was talking about going a bit more green I figured that was ok.

To add yet another color to the mix, how about going a bit more reddish as the modern theme shows? I came up with #FFF5B4 as tilting it a bit more to the modern #E8DB99 without being that dark, thus possibly a better match for the lighter Windows 7 Aero/Basic and Windows Classic themes.

Comment 17

[rsx11m]

Attachment: Windows 7 Aero, #FFFFC7 vs. #FFF5B4

I think both shades would work on the Windows 7 Aero default desktop.
Linux may be hard to tell, the desktop themes vary quite a lot there.

Comment 18

[rsx11m]

Attachment: Patch with pref listener

This is an alternative to attachment 825577 [details] [diff] [review]. It bugged me a bit that changing the pref in one window doesn't take effect immediately in any other window, but only when loading the next page. This version now also installs a listener on the preference, thus changes get triggered as soon as the pref is toggled.

The drawback of this method is that I can no longer just remove the "level" attribute if the pref is false, given that the level may be needed later on when reactivating the highlighting effect. Thus, a second attribute for controlling the "highlight" effect is introduced while leaving the current "level" handling intact.

While this may be cleaner than the other version (especially if we are going to add a checkbox in the UI for this similar to the urlbar formatting preference), it implies that 3rd-party themes will have to be modified to use the additional attribute in their rules (as was done here for the modern theme).

And, this patch now uses #FFFFC7 per Stefan's comment #15.

Comment 19

[rsx11m]

Comment on attachment 826854 [details] [diff] [review]
Patch with pref listener

>+++ b/suite/browser/nsBrowserStatusHandler.js
>+    var highlightSecure =
>+      Services.prefs.getBoolPref("browser.urlbar.highlight.secure");
>+
>+    if (highlightSecure)
>+      this.urlBar.setAttribute("highlight", "true");
>+    else
>+      this.urlBar.removeAttribute("highlight");

I probably don't need the highlightSecure variable here any more and can put this directly into the if(...) clause, given that it's the only occurrence now (and also maybe put it after the switch for easier reading).

Comment 20

[rsx11m]

Attachment: Patch with pref listener (v2c)

Found another issue:

>+++ b/suite/browser/navigator.js
>+    var urlbar = document.getElementById("urlbar");
>+    if (Services.prefs.getBoolPref(prefName))
>+      urlbar.setAttribute("highlight", "true");
>+    else
>+      urlbar.removeAttribute("highlight");

The urlbar variable is redundant here, it's defined globally as gURLBar already. Thus, using that one instead.

That's hopefully it.

Comment 21

[Frank Wein [:mcsmurf]]

Just to get this right: Should I review/feedback both patches?

Comment 22

[rsx11m]

My favorite would be attachment 826975 [details] [diff] [review], though I'm not sure about the implications for themes with the additional attribute necessary, hence I left attachment 825577 [details] [diff] [review] up for review as an alternative patch.

Thus, maybe try the more recent one first, f+ it if you like it, and if you don't like it, proceed with the simpler one?

Either case, we should decide (a) which highlighting color to change to and (b) whether or not a preference is wanted.

Comment 23

[Stefan [:stefanh]]

Comment on attachment 826975 [details] [diff] [review]
Patch with pref listener (v2c)

Naturally, I don't have any objections regarding the color :-) And if we should go for it, we should take this patch. But: I'm hesitating making this a pref since afaics there are only 1-2 people (in this bug) who want it (and they wanted that for 6+ years ago which make me think that they just reacted against the change and that they might have gotten used to it now). Also, people who don't want the url bar highlightning could still get rid of it by userChrome hacks.

I don't really have any strong opinion about this, though - if people want it we can have the pref.

Comment 24

[Felix Miata]

I still object to yellow, still a color of illness, and would welcome a pref to obviate a need for userChrome.css in every profile I create. It seems fewer and fewer pages I load only use http any more anyway, making less secure more exceptional than normal.

Comment 25

[rsx11m]

(In reply to Stefan [:stefanh] from comment #23)
> But: I'm hesitating making this a pref since afaics there are only 1-2 people
> (in this bug) who want it (and they wanted that for 6+ years ago which make
> me think that they just reacted against the change and that they might have
> gotten used to it now).

Well, reading comment #24, apparently not. Also keep in mind that if we make the color more intense, more people may have the wish to switch it off, so...

> Also, people who don't want the url bar highlightning could still get rid of it
> by userChrome hacks.

That was mentioned earlier (comment #2) and given that it's not easy to change the color by a preference setting, I figured that a boolean switch might be a good compromise.

Remember that there is a related pref browser.urlbar.formatting.enabled controlling the graying of the non-domain parts of the URL fonts, I'd see it in that category.
 
(In reply to Felix Miata from comment #24)
> I still object to yellow, still a color of illness

Stefan didn't like the touch of green in return, and it has been yellow since initially introduced. I agree that a too bright yellow may result in a "warning" style rather than conveying something "good" but tend to keep the base color as it has been (and I don't quite like a full green instead either).

Comment 26

[Stefan [:stefanh]]

(In reply to rsx11m from comment #25)
> (In reply to Stefan [:stefanh] from comment #23)
> > But: I'm hesitating making this a pref since afaics there are only 1-2 people
> > (in this bug) who want it (and they wanted that for 6+ years ago which make
> > me think that they just reacted against the change and that they might have
> > gotten used to it now).
> 
> Well, reading comment #24, apparently not. Also keep in mind that if we make
> the color more intense, more people may have the wish to switch it off, so...
Well, it seems more that Felix objects to the color. As I said though, I don't have a strong preference about this, so let's see what the feedback request says.

Comment 27

[Felix Miata]

It's not only about the color itself, but that any colors but black on white (or white on black) are reducing contrast of  a (usually) already suboptimally sized text object. Short text strings pervasive in the most evident UI aren't necessarily bad, because they're both short and quickly familiar. Specific URIs are routinely neither short nor familiar, and so harder to read and edit than ideal even without a contrast reduction.

Comment 28

[Tony Mechelynck [:tonymec]]

(In reply to Felix Miata from comment #27)
> It's not only about the color itself, but that any colors but black on white
> (or white on black) are reducing contrast of  a (usually) already
> suboptimally sized text object.

Are you sure? I've been told that the colors most physiologically contrastive (those evoking the most intense neuron firing) are not black against white but black against yellow. Whether a location bar for an HTTPS URL ought to draw more attention than one for an HTTP URL is a separate question, but I suppose it is also worthy of consideration.

Comment 29

[Frank Wein [:mcsmurf]]

Comment on attachment 825577 [details] [diff] [review]
Patch with on/off preference

Ok, works fine for me and looks fine for me. I + this one as I think a pref listener is really overkill, how likely is it that a user wants to change this pref often? Of course it's nice to have, but overkill IMHO. Also this patch is better when theme authors forget to update their themes (or do not work on them anymore), then those themes still work fine as far as I see it.
At first I was against a new pref, but if someone wants to disable it, so be it. It's a security feature in some way, but as it's not critical, letting the user disable it is fine I guess. On the other hand we could maybe do what Firefox does (yes, I think their current solution is also not that bad): They've no urlbar with yellowish background, but display a lock icon where the favicon used to be (but they've moved the favicon completely out of the urlbar anyway).

Comment 30

[rsx11m]

Attachment: Proposed patch (v3)

Frankly, I don't like the Firefox solution at all. They have a variety of icons that they show in the URL bar in a rather subtle way, and I'm having a hard time memorizing which one has which meaning. My eyes go more by color than by shape, but this may certainly vary from user to user.

Ok, to summarize, per comment #23 and no preferred color stated in comment #29 it seems that #FFFFC7 should be it, unless Neil comes up with a better idea during his review. I've been running with this color on a couple of machines and it looks good to me.

I liked the listener version (which was a helpful learning exercise for that matter) but in fact it's not essential given that this is not an option which would be modified frequently (and yes, not obsoleting themes in this way remains a good argument).

So, here the blend of attachment 825577 [details] [diff] [review] with the color of attachment 826975 [details] [diff] [review].

Comment 31

[Felix Miata]

(In reply to Tony Mechelynck [:tonymec] from comment #28)
> I've been told that the colors most physiologically
> contrastive (those evoking the most intense neuron firing) are not black
> against white but black against yellow. Whether a location bar for an HTTPS
> URL ought to draw more attention than one for an HTTP URL is a separate
> question, but I suppose it is also worthy of consideration.

http://juicystudio.com/services/luminositycontrastratio.php
black on white: The contrast ratio is: 21.00:1
FFFC7 on white: The contrast ratio is: 20.38:1

Whether there is a reversed difference between physical and physiological I have no idea. The physical difference is slight. As yellow and I do not get along, the easier it is for me to avoid yellow, the better.

Also, I like the idea that the default urlbar background matches the default background for input elements in web pages. It's a well understood cue that one can type something in them. A difference, yellow in particular, may be indicative to some of an input inhibition or restriction of some sort.

I think an unambiguous padlock in the urlbar makes vastly more sense than different coloring if the intent is to create awareness of elevated security, if only one manner of increasing awareness is to be implemented. In contrast, if a mere difference in color is the only goal, then I am flat out against it, in part on the basis explained at http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html.

Comment 32

[Philip Chee]

How about using colour names instead?
https://developer.mozilla.org/en-US/docs/Web/CSS/color_value
lightgoldenrodyellow sounds promising.

Comment 33

[rsx11m]

Wow, nice name, but I find "rgb(250, 250, 210)" much more conclusive. ;-)

That's similar to but a bit farther from rgb(255, 255, 199) of the current patch, thus would be less saturated and potentially provide less contrast than the #FFFFC7 version.

Is it recommended to use color names instead? Unless it's a trivial one like red or green, one has to look them up in the table, which isn't quite convenient.

Comment 34

[[e-mail]]

So, the original design decision to use tooltip(text) was that these are a form of alternate highlight colour that will still blend in with the rest of the OS theme in a way that hard-coded colours won't. Obviously this isn't a problem for the Modern theme but it is for Classic. Maybe the way to go here is to have a subtle partial transparency tint?

Alternatively, you could define preferences browser.urlbar.secure.(background-)color.override and then the user could set these preferences to their favourite colours.

Comment 35

[Frank Wein [:mcsmurf]]

With the Linux Ubuntu Unity desktop the tooltip color is totally the wrong choice though. IIRC when visiting a SSL page you have a urlbar with black background and white text. This did not look good at all.

Comment 36

[rsx11m]

(In reply to [e-mail] from comment #34)
> Alternatively, you could define preferences
> browser.urlbar.secure.(background-)color.override and then the user could
> set these preferences to their favourite colours.

It is my understanding that, in order to access those with CSS to be toggled by the theme, this would require a Core change to define the necessary "-moz-*" colors. Also note that different themes are modifying different UI elements, thus I couldn't simply attach a color style derived from that preference to the UI element in question.

So yes, it would be nice to have, but I don't see a straight-forward way how to implement this.

Comment 37

[rsx11m]

(In reply to Frank Wein [:mcsmurf] from comment #35)
> With the Linux Ubuntu Unity desktop the tooltip color is totally the wrong
> choice though. IIRC when visiting a SSL page you have a urlbar with black
> background and white text. This did not look good at all.

Exactly, see attachment 825525 [details] for an example (that's with KDE, not better).

Comment 38

[[e-mail]]

(In reply to rsx11m from comment #36)
> Also note that different themes are modifying different UI elements

Ah, good point.

Comment 39

[[e-mail]]

Comment on attachment 830460 [details] [diff] [review]
Proposed patch (v3)

r=me on the code changes. I guess people with userChrome overrides to remove the colour can use the pref; people providing their own colour override will have to leave the pref on so that they can continue to observe the attribute.

Still not convinced by the colour changes. Windows isn't making my life easier, High Contrast #1 uses yellow on black while #2 uses black on yellow tooltips...

Comment 40

[rsx11m]

I've hard-wired the URL text for that reason to black as well, thus to avoid that the tooltip text color of the desktop theme screws up visibility on the yellow background.

Two reasons for the color changes: Windows has a too light tooltip background color which with the respective monitors setting may become almost invisible and easy to miss; and Linux may have a color scheme that doesn't fit at all (as seen with the gray tooltip background desktop theme). Thus, basing it on desktop theme colors may work fine in some cases but not in others, whereas chances that some desktop theme has a #FFFFC7 yellow as background color for the non-secure http: urlbar are hopefully slim (thus always providing a good differentiation between http: and https: sites).

Comment 41

[Stefan [:stefanh]]

Comment on attachment 830460 [details] [diff] [review]
Proposed patch (v3)

Looks good to me.

Comment 42

[rsx11m]

Neil, any verdict on the color? Frank and Stefan gave it a thumbs up, and I don't know how else to argue or which modifications to the patch to make...

Comment 43

[[e-mail]]

Comment on attachment 830460 [details] [diff] [review]
Proposed patch (v3)

OK, so having read the bug and seeing that we're just moving to hard-coding the Mac colours on all platforms, this seems the most sensible colour choice.

Comment 44

[rsx11m]

Thanks Neil. This hasn't bitrotted yet, thus push for comm-central to catch tomorrow's train, please.

Comment 45

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/d5ca9f7b2beb