Last Comment Bug 654411 - domain highlighting lightens and de-emphasizes the rest of URL too much
: domain highlighting lightens and de-emphasizes the rest of URL too much
Status: VERIFIED FIXED
: access, regression
Product: Firefox
Classification: Client Software
Component: Location Bar (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: Firefox 7
Assigned To: Dão Gottwald [:dao]
:
Mentors:
Depends on:
Blocks: 680648 683811 451833 654809
  Show dependency treegraph
 
Reported: 2011-05-03 04:11 PDT by Stefan
Modified: 2013-12-27 14:33 PST (History)
33 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed


Attachments
screenshot of Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110526 Firefox/7.0a1 (12.88 KB, image/png)
2011-05-31 13:45 PDT, Stefan
no flags Details
screenshot of Mozilla/5.0 (Mac; Intel) ... Gecko/20110530 Firefox/7.0a1 (18.21 KB, image/png)
2011-05-31 15:24 PDT, Rob Campbell [:rc] (:robcee)
no flags Details
Almost invisible URL, Gnome with a dark theme. (5.18 KB, image/png)
2011-06-08 07:16 PDT, nemo
no flags Details
use text color at 60% opacity instead of graytext (1.14 KB, patch)
2011-06-13 04:50 PDT, Dão Gottwald [:dao]
roc: review+
Details | Diff | Splinter Review
screenshot using 60% opacity (34.67 KB, image/png)
2011-06-13 04:51 PDT, Dão Gottwald [:dao]
faaborg: ui‑review-
Details
screenshot using 50% opacity (26.17 KB, image/png)
2011-06-13 05:46 PDT, Dão Gottwald [:dao]
faaborg: ui‑review+
Details
use text color at 50% opacity instead of graytext (1.45 KB, patch)
2011-06-19 02:43 PDT, Dão Gottwald [:dao]
bugzilla: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Stefan 2011-05-03 04:11:35 PDT
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 [:Tyler] 2011-05-03 06:23:56 PDT
So basically the color of the reset of the URL is too faint?
Comment 2 Stefan 2011-05-03 10:12:39 PDT
This and the user story in Bug 451833 are too faint.
Comment 3 Frank Yan (:fryn) 2011-05-03 16:04:52 PDT
Seems like GrayText (CSS color value) is too light on Linux.
Comment 4 Stefan 2011-05-04 02:36:18 PDT
It seems to be #c7c7c7.
Comment 5 patrickjdempsey 2011-05-04 16:20:59 PDT
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] (Away 6-20 Aug) 2011-05-12 02:12:35 PDT
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 [:bz] 2011-05-13 11:43:24 PDT
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) 2011-05-14 10:14:26 PDT
agree with Boris' comment #7. De-emphasized text should be darker.
Comment 9 Zack Weinberg (:zwol) 2011-05-16 16:52:53 PDT
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 2011-05-16 18:19:07 PDT
Could the user choose a color?  Empower the user any chance that comes up.
Comment 11 j.j. 2011-05-16 20:01:30 PDT
(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] 2011-05-31 13:28:40 PDT
Can we get UX to chime in here?
Comment 13 Alex Limi (:limi) — Firefox UX Team 2011-05-31 13:34:03 PDT
I'd be happy to. Can anyone attach some screenshots of current look on Linux?
Comment 14 Stefan 2011-05-31 13:45:02 PDT
Created attachment 536401 [details]
screenshot of Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110526 Firefox/7.0a1
Comment 15 Boris Zbarsky [:bz] 2011-05-31 14:02:14 PDT
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) 2011-05-31 15:22:24 PDT
yes. I don't think this is just a linux issue.
Comment 17 Rob Campbell [:rc] (:robcee) 2011-05-31 15:24:25 PDT
Created attachment 536437 [details]
screenshot of Mozilla/5.0 (Mac; Intel) ... Gecko/20110530 Firefox/7.0a1
Comment 18 Lukas Blakk [:lsblakk] use ?needinfo 2011-06-01 16:56:56 PDT
Is there an about:config setting to enable/disable this feature?
Comment 19 Matt Brubeck (:mbrubeck) 2011-06-01 17:03:52 PDT
(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 2011-06-02 12:06:04 PDT
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 2011-06-08 07:16:26 PDT
Created attachment 538012 [details]
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] 2011-06-08 08:41:59 PDT
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) 2011-06-08 08:59:01 PDT
(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) 2011-06-08 10:09:41 PDT
What if, instead of what we're doing now, we made the domain be boldface?
Comment 25 Boris Zbarsky [:bz] 2011-06-08 11:06:24 PDT
Zack, that would make the text shift around when the user clicks on the url bar, right?
Comment 26 nemo 2011-06-08 11:42:40 PDT
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] 2011-06-08 13:16:25 PDT
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] 2011-06-08 13:29:22 PDT
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] 2011-06-08 14:48:21 PDT
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) 2011-06-08 20:20:40 PDT
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] 2011-06-08 22:11:26 PDT
(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) 2011-06-09 19:14:00 PDT
(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] 2011-06-09 19:46:41 PDT
(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] 2011-06-13 04:50:52 PDT
Created attachment 538860 [details] [diff] [review]
use text color at 60% opacity instead of graytext
Comment 35 Dão Gottwald [:dao] 2011-06-13 04:51:29 PDT
Created attachment 538861 [details]
screenshot using 60% opacity
Comment 36 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-06-13 05:02:09 PDT
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] 2011-06-13 05:08:35 PDT
FWIW, Chrome seems to be using 50% (from what I see on Windows, not from actually reading the code).
Comment 39 Dão Gottwald [:dao] 2011-06-13 05:46:27 PDT
Created attachment 538872 [details]
screenshot using 50% opacity
Comment 40 Dão Gottwald [:dao] 2011-06-16 23:10:43 PDT
http://hg.mozilla.org/mozilla-central/rev/306bdc7101c3
Comment 41 Dão Gottwald [:dao] 2011-06-19 02:43:49 PDT
Created attachment 540304 [details] [diff] [review]
use text color at 50% opacity instead of graytext
Comment 42 Vlad [QA] 2011-06-22 07:13:20 PDT
Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110621 Firefox/7.0a1
Comment 44 Robert Kaiser 2011-07-08 14:46:37 PDT
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) 2012-05-03 04:51:33 PDT
(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.
Comment 46 Robert Kaiser 2012-05-03 09:07:54 PDT
(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 2012-06-07 19:52:57 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.