654411 - domain highlighting lightens and de-emphasizes the rest of URL too much

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Stefan]

User-Agent:       
Build Identifier: Built from http://hg.mozilla.org/mozilla-central/rev/7528b2718827

Since checkin of http://hg.mozilla.org/mozilla-central/rev/63c46c761a92 (Bug 451833) everything except the domain part of the URL in the addressbar is rendered unreadable.

Reproducible: Always

Steps to Reproduce:
1. open http://www.heise.de/newsticker/classic/
2.
3.

Actual Results:  
https://bugzilla.mozilla.org/attachment.cgi?id=529664

Expected Results:  
Keep readability of URL.

Comment 1

[Tyler Downer [He/Him]]

So basically the color of the reset of the URL is too faint?

Comment 2

[Stefan]

This and the user story in Bug 451833 are too faint.

Comment 3

[Frank Yan (:fryn)]

Seems like GrayText (CSS color value) is too light on Linux.

Comment 4

[Stefan]

It seems to be #c7c7c7.

Comment 5

[patrickjdempsey]

For my themes to support LocationBar2 and SmartText I'm using the same color but changing the un-highlighted part of the url slightly transparent and the domain bold.  This method would work better than physically changing the color of the text for both Theme support and for OS support.

Comment 6

[Marco Bonardo [:mak]]

We should at least do a usability check of the grey levels on various OS, users with not-that-good eyes could suffer current situation.

Comment 7

[Boris Zbarsky [:bzbarsky]]

For what it's worth, on Mac the gray is too faint as well.  I tried measuring the actual pixels in the text, and the darkest ones seem to be #7f85b7 or rgb(127,133,183).  And these are very thin strokes, of course.

Just for comparison sake, per http://www.w3.org/TR/AERT#color-contrast that color has a luminosity of (127*299 + 133*587 + 183*114)/1000 == 137.  White has luminosity 255.  Luminosity differences smaller than 125 are generally bad (in the "the colors are too close" sense).

Or from the same page, the color difference between the color above and white is 128 + 122 + 72 == 322, which is also less than the 500 that's recommended for sufficient contrast.

Note that the Linux color listed in comment 4 is much much worse than this....

Comment 8

[Rob Campbell [:rc] (:robcee)]

agree with Boris' comment #7. De-emphasized text should be darker.

Comment 9

[Zack Weinberg (:zwol)]

The observation was made in the newsgroups that gray in a UI tends to mean "disabled".  Can we have, Idunno, a medium dark brown instead?

Comment 10

[Ronald Hunter]

Could the user choose a color?  Empower the user any chance that comes up.

Comment 11

[j.j.]

(In reply to comment #10)
> Could the user choose a color?  Empower the user any chance that comes up.

All power to the users!
http://weblogs.mozillazine.org/bz/archives/020683.html (scr)

Comment 12

[Asa Dotzler [:asa]]

Can we get UX to chime in here?

Comment 13

[Alex Limi (:limi) — Firefox UX Team]

I'd be happy to. Can anyone attach some screenshots of current look on Linux?

Comment 14

[Stefan]

Attachment: screenshot of Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110526 Firefox/7.0a1

Comment 15

[Boris Zbarsky [:bzbarsky]]

Note that I'm on Mac and the light gray is too light there as well: see comment 7.

Comment 16

[Rob Campbell [:rc] (:robcee)]

yes. I don't think this is just a linux issue.

Comment 17

[Rob Campbell [:rc] (:robcee)]

Attachment: screenshot of Mozilla/5.0 (Mac; Intel) ... Gecko/20110530 Firefox/7.0a1

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

Is there an about:config setting to enable/disable this feature?

Comment 19

[Matt Brubeck (:mbrubeck)]

(In reply to comment #18)
> Is there an about:config setting to enable/disable this feature?

Yes, it is "browser.urlbar.formatting.enabled".

Comment 20

[d]

I can read the light gray text quite clearly on OS X as it is, but I realize that this may be both due to that my eyes are still quite young and that people may have their monitors configured in ways that make it harder to read. I like it the way it is now, but if it can be changed to make it easier to read for more people, without getting annoying for those who can now, I suppose it's a good thing.

Comment 21

[nemo]

Attachment: Almost invisible URL, Gnome with a dark theme.

Awesomebar contents are quite readable.  In the past, when Awesomebar was being implemented, it had similar issues with not using the theme colours.

http://intellectualcramps.blogspot.com/2009/08/operating-system-colors-and-css.html

There is a wide variety of choices here - hopefully they can pick some others.

Comment 22

[Dão Gottwald [:dao]]

Comment on attachment 538012 [details]
Almost invisible URL, Gnome with a dark theme.

We're using theme colors; this is a bug in the GTK theme.

Comment 23

[Matt Brubeck (:mbrubeck)]

(In reply to comment #22)
> We're using theme colors; this is a bug in the GTK theme.

The problem is that CSS provides only a single "GrayText" color, while GTK might use different colors for text in menus, buttons, input fields, dialogs, etc.  To match the GTK theme correctly, we would need GrayMenuText, GrayButtonText, GrayWindowText...

Comment 24

[Zack Weinberg (:zwol)]

What if, instead of what we're doing now, we made the domain be boldface?

Comment 25

[Boris Zbarsky [:bzbarsky]]

Zack, that would make the text shift around when the user clicks on the url bar, right?

Comment 26

[nemo]

What about highlight text colour/background colour for the domain? too ugly?
Heck. Awesomebar seems to use 3 colours just fine. link is one colour, title is another.  Both with same background colour, and I haven't run into any theme problems with it since it was being made.

Comment 27

[Asa Dotzler [:asa]]

Bugzilla is not the best tool for this kind of design discussion. This bug has made the issue clear to the UX team and they will either suggest adjustments or resolve the bug as wontfix. If you'd like to discuss this issue with the UX team, I suggest you do so in IRC and not in this report. Thanks.

Comment 28

[Asa Dotzler [:asa]]

Boris, what's already been implemented is the feature as designed by the usability team, the "module owner and peers" for the specific issue being discussed here. 

The status of this bug is that the design team which implemented this feature is evaluating a concern about their design. They know the concern and they will either adjust their design or not. Making a bunch of suggestions in the bug like "maybe we should just make it bold" which have obviously already already been discussed and thought about by the design team and doesn't contribute to a better solution here. 

If someone in this bug has more information about the problem (additional screenshots on other configurations or similar information,) go ahead and post it. If you just want to toss out ideas that have *certainly* already been discussed by the module owner and peers for this feature, you're not helping.

Comment 29

[Asa Dotzler [:asa]]

To follow up to my last comment: off-line, bz suggested it might be more helpful if I'd pointed to the place where this feature was designed, discussed, implemented, bug 451833 -- rather than just telling people to go to IRC. He's absolutely right I should have done that. So, if you want to help out here, then please first familiarize yourself with what this feature before commenting and only comment if you have something new to add. Thanks.

Comment 30

[Zack Weinberg (:zwol)]

I think that asking people to stop discussing this bug here is inappropriate, because:

It is in fact a *bug*: specifically, it is an unintended side effect of a new feature. Resolving it should not need extensive design discussion of the sort that Bugzilla is unsuited for; we have only to figure out what a better color choice would be, or use boldface instead, or something like that.  As such, there is no reason the UX team could not work out the best strategy right here rather than in a less accessible venue.

I take your point that my suggestion of boldface had already been brought up in bug 451833 and rejected for what sound like sensible reasons.  Note however that various other suggestions in there seem to have been completely ignored; perhaps they were considered offline, but there's no way to tell.  Therefore I don't think pointing people other than me at that bug actually helps, and I am not a UI person and my supply of clever ideas has been exhausted at this point.


More generally, the previous three comments threaten to WONTFIX the bug, assert that a decision will be made by an unspecified group of people, imply that said people are not only uninterested in discussing it here but uninterested in discussing it at all, and end with "only comment if you have something new to add."  Taken as a whole, the message is "shut up, go away, and don't expect anything to change."  That is not the message we should be sending anyone who has come to us to report a problem.  Bugzilla is already enough of a technical obstacle for people on the fringes of the community; we should be *compensating* for that with social *rewards* for people who take the trouble, rather than heaping social demerits on them because they don't know the ins and outs of bugzilla etiquette yet.

I myself am not a person on the fringe of the community, but people on the fringe aren't going to call you on the negative consequences of what you said.  They're going to shut up and go away.  And they may never try again to tell us about their problems.

Comment 31

[Asa Dotzler [:asa]]

(In reply to comment #30)
> That is not the message we should be sending anyone who has come to us to report a problem.

Nowhere have I said anything about how people should or should not report problems. I don't appreciate you putting those words in my mouth. I'm talking about people who are attempting to design solutions to those problems in unhelpful ways.

Comment 32

[Zack Weinberg (:zwol)]

(In reply to comment #31)
>
> Nowhere have I said anything about how people should or should not report
> problems. I don't appreciate you putting those words in my mouth. I'm
> talking about people who are attempting to design solutions to those
> problems in unhelpful ways.

That was not clear to me in the least.  Your remarks read as directed to everyone who has posted in this bug (except the one directed specifically at Boris).

Also, my criticism stands, every bit of it, even if your comments are limited to "people who are attempting to design solutions to those problems [in ways that you assert are unhelpful]".  It is never necessary or appropriate to tell people to shut up and go away for anything short of the kind of behavior that warrants an enforced ban.

Comment 33

[Asa Dotzler [:asa]]

(In reply to comment #32)
> It is never necessary or appropriate to tell people to shut up

We disagree and you are wrong. (yeah.)  I suspect you haven't seen enough Bugzilla activity to make that call (where, yes, I have.) 

There are plenty of cases where people should be told to stop making comments in bugs. That you haven't been involved in enough bug discussion to have learned that doesn't negate that obvious (to the overwhelming majority of us who have read hundreds of thousands of Bugzilla comments) fact.

If you'd like to continue to tell me what is and isn't appropriate in Bugzilla, please take it to email or some other forum that doesn't further degrade what ever minimal value is left in this report. I'm happy to debate in a newsgroup or where ever else but not here. Thanks.

Comment 34

[Dão Gottwald [:dao]]

Attachment: use text color at 60% opacity instead of graytext

Comment 35

[Dão Gottwald [:dao]]

Attachment: screenshot using 60% opacity

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 538860 [details] [diff] [review]
use text color at 60% opacity instead of graytext

Review of attachment 538860 [details] [diff] [review]:
-----------------------------------------------------------------

Comment 37

[Dão Gottwald [:dao]]

FWIW, Chrome seems to be using 50% (from what I see on Windows, not from actually reading the code).

Comment 38

[Dão Gottwald [:dao]]

Yeah, it hardcodes a 50% opacity: http://codesearch.google.com/#OAMlx_jo-ck/src/chrome/browser/ui/views/location_bar/location_bar_view.cc&exact_package=chromium&q=DEEMPHASIZED_TEXT&type=cs&l=241

Comment 39

[Dão Gottwald [:dao]]

Attachment: screenshot using 50% opacity

Comment 40

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/306bdc7101c3

Comment 41

[Dão Gottwald [:dao]]

Attachment: use text color at 50% opacity instead of graytext

Comment 42

[Vlad [QA]]

Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110621 Firefox/7.0a1

Comment 43

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/c64b52363a1b

Comment 44

[Robert Kaiser]

Ouch, this makes it really hard for custom themes that have a default address bar color that doesn't have really high contrast to their background. Would it be possible to get some way to make this color themable in the future, as a followup?

Comment 45

[John Drinkwater (:beta)]

(In reply to Robert Kaiser (:[e-mail]) from comment #44)
> Ouch, this makes it really hard for custom themes that have a default
> address bar color that doesn't have really high contrast to their
> background. Would it be possible to get some way to make this color themable
> in the future, as a followup?

Per comment #44, was there a follow up? I filed bug 680648 because of contrast problems on my dark theme. My resolution to that was disable the domain highlighting, but with the changes to the address bar soon, might be worth another look.

Comment 46

[Robert Kaiser]

(In reply to John Drinkwater (:beta) from comment #45)
> Per comment #44, was there a follow up?

No, but I would welcome one.

Comment 47

[Robert Kaiser]

bug 680648 and bug 683811 are basically both filed on the issue of the de-emphasis of the non-domain parts being hardcoded to 50% opacity.