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.

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

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

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

It seems to be #c7c7c7.

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.

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.

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....

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

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?

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

(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)

Can we get UX to chime in here?

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

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

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

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

(In reply to comment #18) > Is there an about:config setting to enable/disable this feature? Yes, it is "browser.urlbar.formatting.enabled".

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.

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 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.

(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...

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

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

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.

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.

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.

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.

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.

(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.

(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.

(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 on attachment 538860 [details] [diff] [review] use text color at 60% opacity instead of graytext Review of attachment 538860 [details] [diff] [review]: -----------------------------------------------------------------

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

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

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

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?

(In reply to Robert Kaiser (:kairo@mozilla.com) 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.

(In reply to John Drinkwater (:beta) from comment #45) > Per comment #44, was there a follow up? No, but I would welcome one.

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.