417844 - SSL appearance for site identity button and location bar should be consistent across platforms

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Steve England [:stevee]]

Max Karl Ernst pointed this out on the mz forums, and it makes sense to me. Why is larry yellow on unsecure sites (white address bar background) and blue on secure sites (yellow address bar background). It's kind of inconsistent and tbh I'm not even sure what the colours are meant to be indicating.

         | address bar | larry logo 
---------+--------------------------
unsecure | white       | yellow   
secure   | yellow      | blue 
EV       | green       | green

Comment 1

[Kris Silver]

This consistency issue needs urgently addressing.  Consistency of colors around security is very important.  Yellow url bars is for secure sites.  Yet Security Larry is yellow on insecure sites, misleading some into thinking the page is in-fact secure.

Comment 2

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

The mismatch occurred by basing the visual design of larry icons on common platform dialog icons.

Johnath: how do you want to address the inconsistent use of color?

Comment 3

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

not blocking on this, for starters, though a fix is wanted

My (perhaps heretical) suggestion: we don't change the URL bar color, ever, only the site identity button colour. Blue for SSL, green for EV SSL, and ditch the yellow. We'll likely get yelled at a lot for that.

Comment 4

[Johnathan Nightingale [:johnath]]

(In reply to comment #3)
> not blocking on this, for starters, though a fix is wanted
> 
> My (perhaps heretical) suggestion: we don't change the URL bar color, ever,
> only the site identity button colour. Blue for SSL, green for EV SSL, and ditch
> the yellow. We'll likely get yelled at a lot for that.

Yeah, this is the direction I was leaning as well, but the yelling, and the changing it at this late stage, are worth considering.  I don't think those people would be yelling arbitrarily, I think they'd be saying that we're already changing a lot about how Firefox communicates security information, and that the more we can keep consistent, the better.

Of course, paired with the Green for EV, yellow looks sort of cautionary.  It's supposed to be "gold," I suspect, but shimmer is a hard thing to communicate in chrome.  So, let's talk options:

1) We remove all loc-bar decorations and keep it exclusively to the site button.  That means some basic styling rules on windows/linux, but on Proto it will mean some new graphics for the site button.  In that case we could keep the Larry icons as-is, and use:

Grey/Default Site button - No SSL
Blue Site button - DV SSL
Green Site Button - EV SSL

As pointed out, this means understandable yelling.

2) We leave the location bar as is, but flip the 64x64 larry icons around to align better with that.  So:

Blue Larry (ghosted passport)* - No SSL
Gold Larry (intact passport)* - DV SSL
Green Larry (intact passport) - EV SSL

* These two graphics are new, though they ought to be easy to generate from the source materials.

I think this is pretty workable, and reduces the UI alteration for existing users, since the ones who don't use the site button will see things basically as they used to be (albeit without a padlock).

In terms of resolving this problem in a "here comes beta 4" kind of way, minimizing impact, I think option 2 is the way to go.  Everyone knows these icons are in flux, I'm just sorry I didn't spot it sooner in the swatches Alex has been posting.

I think that if we go with option 2 though, I will file a followup to look at moving the colour treatment (grey/yellow/green, not grey/blue/green) exclusively to the site button in Firefox.next, because I think that makes more sense in general, and gives our users a version to get used to the mechanism we're using for site identity.

Alex - was there a strong motivation for the colours being the way they are, that I'm forgetting?  What does option 2 mean in terms of turnaround time from our icon devs on the three platforms?

Comment 5

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

>Alex - was there a strong motivation for the colours being the way they are,
>that I'm forgetting?

Yes, these icons are exact replicas of the standard system dialog box icons.  These colors also carry connotations, the yellow we are using is subsequently a very warning yellow.  The gold bar is gold based on a metaphor we are no longer using, I'm personally with beltzner on removing the location bar color entirely and styling the site button.  The change in state of the site button may also encourage users to explore its functionality more, which is a win.

Comment 6

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

Thinking more about it, the color change of the location bar is a nice ambient/peripheral indicator, although then again this might not be the way you want users making trust decisions.

Comment 7

[Dão Gottwald [:dao]]

(In reply to comment #4)
> 1) We remove all loc-bar decorations and keep it exclusively to the site
> button.  That means some basic styling rules on windows/linux, but on Proto it
> will mean some new graphics for the site button.  In that case we could keep
> the Larry icons as-is, and use:
> 
> Grey/Default Site button - No SSL
> Blue Site button - DV SSL
> Green Site Button - EV SSL

I don't think blue is good for the identity button, since blue is a common base color for user interfaces.

Comment 8

[Johnathan Nightingale [:johnath]]

(In reply to comment #7)
> (In reply to comment #4)
> > Grey/Default Site button - No SSL
> > Blue Site button - DV SSL
> > Green Site Button - EV SSL
> 
> I don't think blue is good for the identity button, since blue is a common base
> color for user interfaces.

Yeah, I feel the same way.  It makes sense to me to have blue (or grey, or something sort of informative-but-neutral) as the unidentified larry icon, which can then tie into the base colours of the interface, with more visually distinct colours for the more notable SSL cases.

(In reply to comment #5)
> Yes, these icons are exact replicas of the standard system dialog box icons. 
> These colors also carry connotations, the yellow we are using is subsequently a
> very warning yellow.  The gold bar is gold based on a metaphor we are no longer
> using, I'm personally with beltzner on removing the location bar color entirely
> and styling the site button.  The change in state of the site button may also
> encourage users to explore its functionality more, which is a win.

(In reply to comment #6)
> Thinking more about it, the color change of the location bar is a nice
> ambient/peripheral indicator, although then again this might not be the way you
> want users making trust decisions.

I agree that the changing state of the site button would invite more exploration.  But that change still presumes nailing down the colour-consistency question, and I remain reluctant to change all the old UI mechanisms in one release.

You're right, of course, that the yellow we have for the Larry icon is cautionary, and is in keeping with the system yellows for warning, but this is an area where our UI is pretty divided.  The address bar is gold, and every updated padlock, privacy (except OSX), and key graphic I've seen involves gold as well.

Using a cautionary yellow as the most-commonly-seen indicator feels a bit like warning fatigue too: we're not saying these sites are suspicious or evil, we're saying there's no information.  I know you are as cautious as I am about creating a continuum where red is for super bad sites, and EV-green is for "super good" sites.  I think having blue interrupt that traffic light metaphor in the most-common case is valuable.

I also know, though, that no one thinks as much about icons as you do.  We're pretty crunched for time here, and the inconsistency is sort of obvious, but I don't want to wreck carefully laid plans either.  If we agree (even hypothetically) that removing the location bar highlight is undesirable at this point, is there another way to resolve this?
 

Comment 9

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

>If we agree (even hypothetically) that removing the location bar highlight is >undesirable at this point, is there another way to resolve this?

Two ideas:

-change the identity unknown state of larry away from yellow and use more of a ghosted / wireframe appearance.

-use the exact same color to underlay the encryption message to reinforce that gold == padlock.

In particular I'm reluctant to make a golden larry icon because that feels like a stronger level than even green, and frankly a little bling.  It also feels like we wold be simply replacing the golden lock with a different golden metaphor, as opposed to focusing on identity.  I really like how blue doesn't land on the spectrum between good and evil.  Also as you note we are really short on time.

Comment 10

[Johnathan Nightingale [:johnath]]

(In reply to comment #9)
> >If we agree (even hypothetically) that removing the location bar highlight is >undesirable at this point, is there another way to resolve this?
> 
> Two ideas:
> 
> -change the identity unknown state of larry away from yellow and use more of a
> ghosted / wireframe appearance.
> 
> -use the exact same color to underlay the encryption message to reinforce that
> gold == padlock.
> 
> In particular I'm reluctant to make a golden larry icon because that feels like
> a stronger level than even green, and frankly a little bling.  It also feels
> like we wold be simply replacing the golden lock with a different golden
> metaphor, as opposed to focusing on identity.  I really like how blue doesn't
> land on the spectrum between good and evil.  Also as you note we are really
> short on time.

I actually really like the idea of changing the unknown state to something ghosted/wireframe.  It captures what I think we want to say, while steering entirely clear of the traffic light game.  I think we can do that independent of your second suggestion, and resolve this bug, though that second suggestion is probably a good idea on its own, establishing the link more explicitly.

Let's go with this (wireframe/ghosted larry for non-SSL, instead of yellow) absent any objections from beltzner.  

Comment 11

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

This is a little off topic, but for the EV state the Green/Yellow combination really doesn't look that great.  I know you want the user to look at the identity button to make a trust decision based on the text, as opposed to processing the ambient display of information using peripheral vision and thinking "ok, every thing is green," but could we consider a very light shade of green in the location bar for EV certs?

Comment 12

[Samuel Sidler (old account; do not CC)]

http://blog.johnath.com/index.php/2007/06/04/will-firefox-have-a-green-bar/ ?

Comment 13

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

mconnor mentioned on a call a few minutes ago that he was in favor of resolving the issue by switching the color of the location bar from yellow to blue.

Comment 14

[Mike Connor [:mconnor]]

er, correction, by changing the site button to blue, not the textfield...  then the field never changes.

Comment 15

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

>er, correction, by changing the site button to blue, not the textfield...  then
>the field never changes.

In my opinion that is even better.

Comment 16

[Max Karl Ernst]

Ok, here's my few puny thoughts about this :)

1. Page security info SHOULD NOT be under favicon. Favicon should be in address bar. Favicons are cosmetics that come in different shapes, sizes, colors, and they shouldn't be allowed to disturb clear perception of UI. People tend to remember pictures not functions, so they seek for familiar shape in the interface and it takes extra effort if that shape changes on every page.

2. Following that line, I think page info button should be clearly separated(as it is) and have simple icons and color that spans whole address bar. If it's padlock than it should be padlock everywhere, if it's Larry then Larry everywhere. I can understand dilemma with open/closed padlock metaphor, but I don't see Larry replacing them here either because it's too unclear at these small sizes. 
For me the logical icon for site identity would be in form of face with just contours and question mark for sites that provide no verification of identity. It is a old metaphor and I always think the less new shapes brought in the better. 

Anyway, information should be persistent throughout interface, statusbar padlock should not appear and disappear, space around page icon should not expand on EV sites and change color. Information has to be ALWAYS present. If it's unverified site, UI informs you about that using exactly the same basis as when it informs you site is verified. You don't just add special alarms like beep 2 times when it's secure site or flash addressbar when it's a forgery :)

Comment 17

[Johnathan Nightingale [:johnath]]

(In reply to comment #15)
> >er, correction, by changing the site button to blue, not the textfield...  then
> >the field never changes.
> 
> In my opinion that is even better.

Yeah, I'd definitely prefer this too.

This will require graphics work, at least on Mac, since we'll need a new, tinted version of the site button background for DV.   

Other than that, it's mostly just CSS changes, but we'll need to get those graphics sorted out pretty quickly, and see if there are messy interactions with on windows with bug 414183.

Comment 18

[Chris Forbes [:chrisjf]]

I agree that we should move away from the the URL bar changing colours. The Identity Button should change colours to denote the encryption level of the site because this will hopefully promote people to click on the button.

This mockup created by Alex Faaborg in bug 414183 is good. But the SSL version of the Identity Button should be coloured.
https://bugzilla.mozilla.org/attachment.cgi?id=299530

On the matter of colour, I don't think we should change the SSL to blue. People already know from Firefox2 that (dark) yellow means (some level of) encryption.

Because we are short on time, I think you should just swap the Larry Icons for Normal and SSL (and possibly darken the yellow icon a bit.) Then we'd have... 

Normal:
-ID button: white (or grey for Mac?)
-Larry: blue (or possibly ghosted if there is time?)

SSL:
-ID button: yellow
-Larry: yellow

EV:
-Id button: green
-Larry: green

Comment 19

[Johnathan Nightingale [:johnath]]

(In reply to comment #17)
> (In reply to comment #15)
> > >er, correction, by changing the site button to blue, not the textfield...  then
> > >the field never changes.
> > 
> > In my opinion that is even better.
> 
> Yeah, I'd definitely prefer this too.
> 
> This will require graphics work, at least on Mac, since we'll need a new,
> tinted version of the site button background for DV.   
> 
> Other than that, it's mostly just CSS changes, but we'll need to get those
> graphics sorted out pretty quickly, and see if there are messy interactions
> with on windows with bug 414183.

Bug 419772 landed last night and has precisely these changes in it.  The presentation there is currently:

HTTP - Yellow Larry, Grey site button, white url bar
DV SSL - Blue Larry, Blue site button, white url bar
EV SSL - Green Larry, Green site button, white url bar

I do still think ghosted Larry is preferable to yellow Larry, if we can get a treatment we're happy with, but at least this resolves the direct ambiguity on one platform.  

Comment 20

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

>I do still think ghosted Larry is preferable to yellow Larry

I'll be requesting that icon from all of the themeing teams after the beta 4 freeze.

Comment 21

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

Johnath: do we have a plan to get this implemented on windows?

Comment 22

[Johnathan Nightingale [:johnath]]

(In reply to comment #21)
> Johnath: do we have a plan to get this implemented on windows?
> 

It's on my radar - just need to deal with string changes and high-priority blockers first.  Now that bug 414183 is in, I'll take a look at what's involved in the necessary styling changes, but my hope is that it's pretty straightforward.

Comment 23

[Dão Gottwald [:dao]]

Yes, changing the background color is trivial on Windows. Make sure to also specify an appropriate text color.

Comment 24

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

I'll try to get background images posted to this bug soon so we can get this in for beta 5.

Comment 25

[Johnathan Nightingale [:johnath]]

Just as an update here, with the latest round of Larry icon landings for beta 5, this bug is now totally resolved on Mac, which now uses:

HTTP - Grey button, grey Larry
SSL - Blue button, blue Larry
EV - Green button, green Larry

On Windows/Linux, the HTTP icon has also changed to grey, so that the inconsistency between the location bar being yellow on SSL and Larry being yellow on non-SSL is a non-issue.  However, it is still desirable to get windows and linux behaving as Mac does with the colour of the site button itself, and with the removal of the urlbar background.  That is just waiting on the icons from Alex.  Changing the summary to match.

Comment 26

[Bill Gianopoulos [:WG9s]]

If this is really going to be done, then shouldn't there be another beta to include the change?

What am I missing here.  I thought it has always been that changes that impact themes were supposed to be included in the last beta version so that themers could design their themes against the beta to make sure everything works before the release.

Comment 27

[Dão Gottwald [:dao]]

http://forums.mozillazine.org/viewtopic.php?t=643573

(In reply to comment #26)
This is actually a theme bug. You wouldn't have to adopt this change in a custom theme.

Comment 28

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

I am renominating this bug because using an inconsistent color and location of the visual cue across platforms makes our security UI more confusing overall.  We might not be able to get all of the browser vendors using the same UI, but we should at least be consistent between Firefox on Windows and OS X.

Comment 29

[Victor Bielawski]

(In reply to comment #28)
> I am renominating this bug because using an inconsistent color and location of
> the visual cue across platforms makes our security UI more confusing overall. 
> We might not be able to get all of the browser vendors using the same UI, but
> we should at least be consistent between Firefox on Windows and OS X.

And Linux? IIRC that's the easiest to change.

Comment 30

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

For some reason I thought linux had moved to the OS X behavior, but I guess I was thinking of their new open search discovery UI.

Comment 31

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

The consistency requirement blocks, though things have changed such that:

 non-ssl = normal button background
 ssl     = blue button background
 ev ssl  = green button background

The button backgrounds are already in place on OSX, and new backgrounds for Windows are coming soon (Alex to provide).

Comment 32

[Johnathan Nightingale [:johnath]]

(In reply to comment #31)
> The consistency requirement blocks, though things have changed such that:
> 
>  non-ssl = normal button background
>  ssl     = blue button background
>  ev ssl  = green button background
> 
> The button backgrounds are already in place on OSX, and new backgrounds for
> Windows are coming soon (Alex to provide).

Given the anticipated lack of change in browser.identity.ssl_domain_display (bug 414627), changing the location bar colour to be always white, and relying only on site button colour, may decrease the visibility of changes in security state, depending on how visible the change between site button colours actually is.

I don't think that generically tinting the location bar yellow on https sites is an effective way to help users make better security decisions, and I do think that site identity is, so I would still support a change that just replaced the button colours, and removed the URL bar highlight as described here. I know that others like dveditz are concerned that the site button + status bar encryption indicators are not enough, though (bug 414627 comment 26).

We could restore consistency by replacing the highlight on Mac, or we could mitigate the concern by using identity-specific highlighting (blue location bar tint for DV, green for EV).  I have ranted before about the green bar sending messages about the site that are really about the owner of the site, and that being a dangerous blurring, but I'm just trying to come up with other options here, if we really don't think that the site button + status bar backup will be enough.

Comment 33

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

>Given the anticipated lack of change in browser.identity.ssl_domain_display
>(bug 414627)

I'm find the change in size of the site button to be what captures my focus when entering and exiting an ssl connection.  If we are not going to use the domain name, perhaps place a word or icon on the ssl site button to create this additional size change?

Comment 34

[Chris Forbes [:chrisjf]]

I think changing the size of the site button is a really great idea. I would suggest "Connection Encrypted". Or if that is too long maybe just "Encrypted"?

(I think I would prefer the domain but there is debate about whether to include subdomains. I.e. icio.us or del.icio.us)

Comment 35

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

(In reply to comment #32)
> I don't think that generically tinting the location bar yellow on https sites
> is an effective way to help users make better security decisions, and I do

Then we shouldn't do it. I agree with you that it helps few people, and have been surprised to discover that we haven't heard more outcry against removing it on OSX - it lends confidence to the argument that people don't really notice it, and those who do can be taught to look for something else.

If we believe the best way to call attention to SSL is through an understanding of identity, then let's do it that way. If your concern is that a blue highlight isn't, by itself, noticeable enough, then we can try to make the background an APNG which glows gently once and settles or something else to get user attention.

(In reply to comment #34)
> I think changing the size of the site button is a really great idea. I would
> suggest "Connection Encrypted". Or if that is too long maybe just "Encrypted"?
> 
> (I think I would prefer the domain but there is debate about whether to include
> subdomains. I.e. icio.us or del.icio.us)

No string changes at this point, and the objections to bug 414627 are mostly due to the size of the button changing, so it seems disingenuous to try and get that done in this bug as opposed to that one.

Let's keep this bug about the issue in the summary.

Comment 36

[Dão Gottwald [:dao]]

I don't understand why we're waiting for images here. We can use CSS colors like we do in the EV case, and add new background images once they are ready.

Comment 37

[Johnathan Nightingale [:johnath]]

Are images expected here soon - or should we be doing as Dao suggests, styling with CSS colors and move to images as a follow-up?

Drivers decided bug 414627 as having no text in the DV case - do they want to offer a decision wrt to yellow-background as well?  The two are clearly linked, in terms of how much cueing we offer for SSL presence, outside of EV.

Comment 38

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

>I don't understand why we're waiting for images here. 

We want the button to feel like chrome instead of content.  The texture of the image makes it feel like the other button in the interface.  I realize I'm blocking here, I have the images just need to get them merged together and landed.  I'll post an update here when they are in.

Comment 39

[Dão Gottwald [:dao]]

I'm not saying that the texture shouldn't be updated. The proposed UI change was just never bound to such an updated texture. We have been and are wasting valuable testing time.

Comment 40

[Mike Connor [:mconnor]]

I think at this point, removing the yellow background is the way we should go.  Its never been good for accessibility/random OS themes, and without the lock its rather meaningless.

Comment 41

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

images will land with bug 429689

/winstripe/browser/siteButtons.png
/winstripe/browser/siteButtons-aero.png

sorry for the delay

Comment 42

[Dão Gottwald [:dao]]

These images won't scale vertically. The default state is also fully opaque, overriding the native ButtonFace color. Same for the border color.

Comment 43

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

>These images won't scale vertically

The default options for increasing fonts in XP and Vista do not change the size of the site button.  However, it is possible if you max all of the font sizes in XP to make the site button 41 pixels tall instead of 22, I'll attach an image of what that looks like so we can decide if that is a reasonable visual degradation given a rather obscure boundary case.

>The default state is also fully opaque,
>overriding the native ButtonFace color. 

I know, we'll get that fixed but I wanted to get the files up. 

>Same for the border color.

For the normal state I think it makes sense to try to use the system border color, and crop out the center of the button.  However, for SSL and EV, isn't a native border color going to look pretty strange surrounding these types of images?

Comment 44

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

Attachment: Stretched site button

Here is what the site button looks like when you manually customize windows XP to use a 24 point font in the advanced options of the os theme.  The default preferences for extra large fonts in XP and Vista do not change the height of the site button.  Personally I think a worse looking boundary case is worth getting the slight glow on the left side.

Requesting ui-r from beltzner to get his feedback.

Comment 45

[Reed Loden [:reed]]

(In reply to comment #44)
> Created an attachment (id=316457) [details]
> Stretched site button

Where's the favicon now?

Comment 46

[Johnathan Nightingale [:johnath]]

I'll defer to beltzner on the acceptability of the stretching on tall location bars - images like these create a certain brittleness -  but I do like the default visual effect significantly more than our current pure-CSS styling.

(In reply to comment #45)
> (In reply to comment #44)
> > Created an attachment (id=316457) [details] [details]
> > Stretched site button
> 
> Where's the favicon now?

They aren't in his attachment, but there is no plan to move the favicon as part of this bug.

Comment 47

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

>> Created an attachment (id=316457) [details] [details]
>> Stretched site button

>Where's the favicon now?

I didn't add it to the mockup partly because I was lazy and partly so we could get a better look at how bad the site button might appear when the user has a 24pt font in the location bar.

Comment 48

[Dão Gottwald [:dao]]

(In reply to comment #43)
> For the normal state I think it makes sense to try to use the system border
> color, and crop out the center of the button.  However, for SSL and EV, isn't a
> native border color going to look pretty strange surrounding these types of
> images?

Using a CSS border in one case and an image in others sounds messy. We could just change the color of the CSS border to match the SSL and EV face.

Note that we cannot stretch background images. Therefore the image should be taller like the tabs' texture:
http://mxr.mozilla.org/seamonkey/source/browser/themes/winstripe/browser/tabbrowser/tab-bkgnd.png

Comment 49

[Dão Gottwald [:dao]]

(In reply to comment #48)
> We could
> just change the color of the CSS border to match the SSL and EV face.

That was wrong, the top and bottom border belongs to the textbox, so we're stuck with ThreeDShadow currently.

Comment 50

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

Since we are running out of time, should we use the current images for the normal state, or do I need to request changes for the normal site buttons and the search button (transparency, color)?

Comment 51

[Mike Connor [:mconnor]]

Current images are ok, I think.  Minimal changes wherever possible.

Johnathan will have a tested patch in the morning, I'll review when its ready.

Comment 52

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

Comment on attachment 316457 [details]
Stretched site button

I agree with faaborg on optimizing for the primary case, fwiw. I'm also not too fussed if the border of the button stays as 3dface or whatever.

Comment 53

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

A best of both worlds is, actually, possible. 

== on the button border ==

We specify the border colour of the identity button here:

http://mxr.mozilla.org/mozilla/source/browser/themes/winstripe/browser/browser.css#1793

We also have selectors for the various states:

 identity-box
 identity-box.verifiedDomain
 identity-box.verifiedIdentity

So we could use the existing treatment and for ...

.. identity-box, keep the border as currently declared in browser.css

.. identity-box.verifiedDomain & identity-box.verifiedIdentity, set the border to be transparent (thus using the borders in provided in SiteButton.png)

== on the base state image issue ==

We'll ask IconFactory to provide updated base state transparent icons to provide the desired effect. In the meantime, I think we should move forward with what we have.

Many thanks to Alex for helping me understand this issue.

Comment 54

[scratch]

I'm fairly certain that only specifies the left and right borders of the identity button, but not the top and bottom borders.

Comment 55

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

(In reply to comment #54)
> I'm fairly certain that only specifies the left and right borders of the
> identity button, but not the top and bottom borders.

Yes, but it *could* override the top and bottom as well, couldn't it?

Comment 56

[scratch]

I don't think so.  The CSS used to get the curve radius on the left border of the identity-box is pretty wild.  I certainly wasn't able to get it to work, at least, and I tried everything but the kitchen sink.  I bet you could do it with some underlying XUL changes, adding in yet another container with a left margin that starts it past the curve...

Comment 57

[Dão Gottwald [:dao]]

The element could override the top and the bottom, but we can't draw a CSS border there. The main problem still is that the images have a fixed height.

More comments on the images:
1) The "button" is a xul:box, which I think means that there's no :active state.
2) They assume that there's an RTL curve. There isn't such a thing at the moment.

Comment 58

[Dão Gottwald [:dao]]

Attachment: texture + css borders

This is a ThreeDDarkShadow on the left and right sides and ThreeDShadow from the textbox at the top and the bottom.

Comment 59

[Johnathan Nightingale [:johnath]]

(In reply to comment #58)
> Created an attachment (id=317236) [details]
> texture + css borders
> 
> This is a ThreeDDarkShadow on the left and right sides and ThreeDShadow from
> the textbox at the top and the bottom.

Do you already have a patch that does this, or is this just a mockup?

Comment 60

[Dão Gottwald [:dao]]

Something in between. I was using DOM Inspector, so the code is basically there.

Comment 61

[Johnathan Nightingale [:johnath]]

Well I just got in, and am starting to look at it now, but I know which of us is the more hardcore CSS ninja - so anything you want to attach will be gleefully stolen.  :)

Comment 62

[Dão Gottwald [:dao]]

Well, there isn't really anything to attach. I've changed the background image and border color of |#identity-button > hbox| and the border color of |#urlbar .textbox-input-box|. You'd also have to create taller textures based on siteButtons.png, which is more tricky.
If attachment 317236 [details] is what we want to do, I can just take the bug.

Comment 63

[Johnathan Nightingale [:johnath]]

(In reply to comment #62)
> Well, there isn't really anything to attach. I've changed the background image
> and border color of |#identity-button > hbox| and the border color of |#urlbar
> .textbox-input-box|. You'd also have to create taller textures based on
> siteButtons.png, which is more tricky.

I was more concerned about the ability to stretch the button horizontally, and whether we'd have to use the mac approach of separate start, mid, and end caps to get it to size-to-fit in the EV (and DV with non-default pref) cases.

> If attachment 317236 [details] is what we want to do, I can just take the bug.

To be honest, and I know Mike and Alex have stronger feelings about the borders than I do, but attachment 317236 [details] represents a substantial improvement to me over the present state of things.  After IRC conversation to ensure this wasn't taking you away from other onslaught, I'm just as happy to have you take it.

This bug is also about removing the yellow highlight on windows and linux (indeed, that's what it was originally about) so we should strike the obvious 4 lines from browser.css on both platforms.  I do not think we should remove the browser code that sets the "level" property on the urlbar, since other themes may rely on it, and we haven't given themers warning.

Comment 64

[Dão Gottwald [:dao]]

It should be possible to tweak the border further.

Comment 65

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

Attachment 317236 [details] is looking better than what we have, for sure. This is a pretty significant user-facing change, though, so I think I need to see/play with it a bit before totally deciding. The progress is, as Johnath says, very promising.

If there's some simple userChrome.css that I can insert (or modifications to browser/browser-aero.css) to be able to actually test this out and get a better feeling for what it looks like, that'd be great.

Comment 66

[Johnathan Nightingale [:johnath]]

Attachment: remove yellow background (no button styling)

(In reply to comment #40)
> I think at this point, removing the yellow background is the way we should go. 
> Its never been good for accessibility/random OS themes, and without the lock
> its rather meaningless.

Well that part is quite straightforward.  As I mention above, I don't think we should remove the code in browser.js that sets the "level" property on urlbar, so this is purely removing the relevant rules from css.

Dao seems to have the site button aspects well in hand.

Comment 67

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons.png

Doesn't look pretty with bigger font sizes, but that can be tweaked later and by others.

Comment 68

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons-aero.png

Comment 69

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons-aero.png

Comment 70

[Dão Gottwald [:dao]]

Attachment: patch

Comment 71

[Kai Liu]

Just out of curiosity, is there a perf penalty for tiling 1px-wide images? (vs. making the image wider and tiling less)

Comment 72

[Dão Gottwald [:dao]]

Comment on attachment 317291 [details] [diff] [review]
patch

No simple userChrome.css, sorry...

Comment 73

[Joe Drew (not getting mail)]

It is conceivable to me that there could be a perf hit for tiling 1px wide images, especially since we don't do anything smart with them and I doubt any vendors (e.g. Apple with Quartz, the Render extension, etc) do anything smart when tiling images. The most straightforward way of implementing tiling of images is slow, which means that most places are probably doing it slowly.

Making any premature optimization decisions based on this is probably a bad idea, though. My advice is to stick with 1px-wide images.

Comment 74

[Dão Gottwald [:dao]]

I was just going to say that I don't know if tiling is slow in Gecko these days. I would have guessed it doesn't really matter.

Comment 75

[Kai Liu]

I know that Gecko 1.8 will take a perf hit when tiling 1px images.  Don't know if that's relevant any more with Cairo, which is why I asked.

FWIW, Microsoft does not use 1px images for tiling.  As a random example, the task bar bitmap in Luna is 50px wide.  There shouldn't be much harm in making the tiling image wider; because of the way PNG compression works, the change in file size would be negligible.

Comment 76

[Ryan A. C.]

I'm sure there's a fine balance somewhere. At some point you're going between png rendering performance, gecko tiling performance, and -moz-image-region performance which I'm sure do different things depending on the png. Out of habit I tend to make tile images 5px because it's easier to see what it is when working with the image files.

Comment 77

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons.png (5px wide)

Comment 78

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons-aero.png (5px wide)

Comment 79

[Dão Gottwald [:dao]]

Attachment: updated patch

Comment 80

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

Attachment: the three states, in Vista

Comment 81

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

Attachment: the three states, in Vista (Classic)

Comment 82

[:Gavin Sharp [email: [e-mail]]]

Attachment: the three states, in XP (Classic)

Comment 83

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 317346 [details] [diff] [review]
updated patch

>Index: browser/themes/winstripe/browser/browser-aero.css

>+#urlbar[chromedir="ltr"] > #identity-box:hover > hbox {

We should probably add chromedir to #identity-box at some point and simplify all these selectors.

Comment 84

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

Thanks for the patch, Dao, and the screenshots, Gavin.

To my eye, this looks OK on XP and Windows Classic, but the gradient seems a little too dark and glossy on Vista - favicons seem to get lost, and the white text in EV is hard to read - and the lighter border on Vista doesn't work well with the 1px white keyline around the gradient.

I do think, on the whole, using the URL bar's border around the button works better than I had expected. I'm trying to picture how it would look if we changed the colour of the border to match the gradient, and especially on Vista where those gradients are dark, I think it might end up making the button look less intregrated with the URL bar. 

Using this patch also puts us in a good position where we can tweak the gradients easily by modifying the navbox-textbox-buttons-*.png files. To that end, I'd suggest:

 XP: no change
 Vista: remove 1px white keyline, desaturate gradient (maybe match it more against the lighter parts of the Larry icons instead of the darker parts)

Alex: your thoughts?

Comment 85

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

>Alex: your thoughts?

As mentioned in person, I'm curious to see what this these look like with the native vista text field.  We would probably need to add a line on the images for the normal case so we don't regress back to bug 426009.

I'm also curious how these patches mesh with bug 428878.

Comment 86

[Kai Liu]

Attachment: with the square buttons patch

(In reply to comment #85)
> I'm also curious how these patches mesh with bug 428878.
>
Here you go...

With all the recent changes, the patch in bug 428878 keeps getting bitrotted.  I'm planning on updating it once this bug and bug 422559 lands.

Comment 87

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

What do people think about the normal site button state gradient?  For instance the middle in in https://bugzilla.mozilla.org/attachment.cgi?id=317467 site button vs search button.

If we want this updated I should send the feedback to the iconfactory tonight.

Comment 88

[Kai Liu]

(In reply to comment #87)
> What do people think about the normal site button state gradient?
> 

I think it looks a little flat.  Probably a combination of the subtler gradient and the lighter color?

(For some reason, I can't stop thinking about vanilla ice cream when I see that.  Maybe I just need a snack.)

Comment 89

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

Comment on attachment 317346 [details] [diff] [review]
updated patch

Let's go with this approach to start, but I'd like to keep tinkering a little to see if we can optimize the appearance, so let's leave this open.

Comment 90

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

(In reply to comment #86)
> Created an attachment (id=317467) [details]
> Here you go...

Hm. What's the black line on the right side of the button in EV and DV states? That looks pretty odd to me. Easy to remove?

(In reply to comment #87)
> What do people think about the normal site button state gradient?  For instance
> the middle in in https://bugzilla.mozilla.org/attachment.cgi?id=317467 site
> button vs search button.

I like the one in the search button better, tbh. Looks more native to my eye, so let's go with that.

So, after that, I think we're at a mostly-working-well state on XP and Vista Classic.

Vista itself, however, still looks a little strange, and that's because of the light grey border we've put around the location bar. The result is that the edge of the site button doesn't match up visually with respect to the edges of the other buttons on the location bar, specifically the back/forward button that we're already mirroring in shape.

There are three ways I can think of to approach this (all Vista only):

1. As Alex mentions, go back to a native textarea for the location bar.

2. Use images, like pinstripe does, to draw the curve and then the body of the button. This has a slight disadvantage of not stretching properly if someone goes through a non-standard sequence of steps to see just how big they can make their fonts (it'll work fine with the standard windows ways of getting large fonts)

3. Modify the gradients such that instead of a white border line, there is a dark coloured border line which will abut the light grey border of the location bar - this should make things look like the button is set inside the location bar.

Regardless, we'll need to modify the gradients of the Vista buttons, as they're a little too dark for favicons at the moment.

Comment 91

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

>if someone goes through a non-standard sequence of steps to see just how big >they can make their fonts

This is very non standard, they would have to switch to classic, then go into advanced settings for the os theme, find the right item to change, and then manually increase the size to 24.  There are two much more obvious ways of setting larger fonts that won't effect the height of the location bar on Vista (dpi settings for aero, and drop down on the theme tab for classic).

Comment 92

[Kai Liu]

If you want to see what it'll look like with a native address bar in Vista, the following userChrome.css will restore a native address bar look for Aero...

#urlbar {
  -moz-appearance: TextField !important;
}

#urlbar[chromedir="ltr"] {
  -moz-margin-start: 4px !important;
}

#urlbar[chromedir="ltr"] > #identity-box {
  -moz-margin-start: 0px ! important;
}

#urlbar[chromedir="ltr"] > #identity-box > hbox {
  border-left-style: none ! important;
  padding-left: 2px ! important;
  -moz-border-radius: 0px ! important;
}

/* bug 429310 */
#urlbar > .autocomplete-history-dropmarker {
  -moz-appearance: menulist-button !important;
  margin: -1px -1px -1px 0 !important;
}

.searchbar-textbox {
  -moz-appearance: TextField ! important;
}

Comment 93

[Dão Gottwald [:dao]]

Attachment: patch (chromedir nit addressed)

Comment 94

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons.png

Comment 95

[Dão Gottwald [:dao]]

Attachment: navbar-textbox-buttons-aero.png

I removed the white border line from the gradient and made the default state more transparent. I expect that the images will be revised, so I'm not going to request another review for this update.

Comment 96

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

re: comment 95, yup, a=beltzner.

Comment 97

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

Attachment: (Vista) using dao's no-whiteline images

Comment 98

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

Attachment: (Vista) using dao's no-whiteline images & native textarea

Comment 99

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/base/content/browser.xul 	1.464
mozilla/browser/themes/gnomestripe/browser/browser.css 	1.211
mozilla/browser/themes/winstripe/browser/browser-aero.css 	1.7
mozilla/browser/themes/winstripe/browser/browser.css 	1.208
mozilla/browser/themes/winstripe/browser/jar.mn 	1.91
mozilla/browser/themes/winstripe/browser/navbar-textbox-buttons-aero.png 	1.1
mozilla/browser/themes/winstripe/browser/navbar-textbox-buttons.png 	1.1
mozilla/browser/themes/winstripe/browser/searchbar.css 	1.27 

Comment 100

[Darren Kalck [:D-Kalck]]

Attachment: Site button border bug

There's a bug on the site button, the right border is 2 pixels wide and it should 1 pixel wide.

Comment 101

[Dão Gottwald [:dao]]

(In reply to comment #100)
> Created an attachment (id=317810) [details]
> Site button border bug
> 
> There's a bug on the site button, the right border is 2 pixels wide and it
> should 1 pixel wide.

You're using the Locationbar² extension. It will be fixed in the next release.

Comment 102

[Darren Kalck [:D-Kalck]]

Thanks Dão, installing 1.0rc1 fixed the problem.

Comment 103

[Sam Johnson]

The curve on the location bar is white on Vista when using a WindowBlinds skin ever since this was checked in.

Comment 104

[Matt Cosentino]

Attachment: Screenshots of colored borders to match the gradient.

There was a lot of talk about using the colored border of the gradients but I didn't see anyone that actually did it.  Here is how it looks on XP.  These are screenshots from a working implementation that includes hover and active states(not shown).  I just feel that matching the forward button makes for a much more consistent and overall better looking interface.  If we've decided not to go this route then that's ok, I just felt like I should put this out there.

Comment 105

[Kai Liu]

(In reply to comment #104)
> There was a lot of talk about using the colored border
> 

That option was considered in bug 430767

Comment 106

[Matt Cosentino]

Maybe I'm just missing it, but what was the reason for not going this route?  It seemed that they liked it but just didn't have an implementation.

Comment 107

[Dão Gottwald [:dao]]

(In reply to comment #104)
> Created an attachment (id=319056) [details]
> Screenshots of colored borders to match the gradient.
> 
> There was a lot of talk about using the colored border of the gradients but I
> didn't see anyone that actually did it.  Here is how it looks on XP.  These are
> screenshots from a working implementation that includes hover and active
> states(not shown).

File a bug, propose a patch?

Comment 108

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

>There was a lot of talk about using the colored border of the gradients but I
>didn't see anyone that actually did it.  Here is how it looks on XP.

I filed the follow up bug 432355.

Comment 109

[Sam Johnson]

(In reply to comment #103)
> The curve on the location bar is white on Vista when using a WindowBlinds skin
> ever since this was checked in.
> 

Sill not fixed.

Comment 110

[Eddy Nigg (StartCom)]

Attachment: SSL on Linux

Following up from bug 383183 where I complained about missing (yellow) color in the address bar for Linux. Now this looks nowhere close to the attachment 319056 [details], is absolutely disgusting and doesn't allow anywhere nearly to distinguish between plain and secured. Now all one needs to do is perhaps use different favicon icons for plain and secure to fake the tiny difference between the two states.

Comment 111

[Kai Liu]

(In reply to comment #110)
> Now this looks nowhere close to the attachment
It doesn't look like that on Windows, either.  For starters, the eTLD+1 text is not enabled by default, so 319056 is not representative of how it looks on Windows.  On Windows, it looks more like attachment 318834 [details]

> Now all one needs to do is perhaps use
> different favicon icons for plain and secure to fake the tiny difference
> between the two states.
It won't be a very good forgery...

FWIW, there was some talk in bug 430790 (which is probably a better place to continue this discussion) about the small size of the Larry button on Linux (and I agree, it's a bit on the small side...)