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

VERIFIED FIXED in Firefox 6

Status

()

Firefox
Location Bar
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: Stefan, Assigned: dao)

Tracking

(Blocks: 2 bugs, {access, regression})

Trunk
Firefox 7
access, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox6+ fixed)

Details

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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?
Blocks: 529664
Version: unspecified → Trunk
(Reporter)

Comment 2

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

Updated

6 years ago
No longer blocks: 529664

Updated

6 years ago
Blocks: 451833
Component: General → Location Bar
QA Contact: general → location.bar

Comment 3

6 years ago
Seems like GrayText (CSS color value) is too light on Linux.
(Reporter)

Comment 4

6 years ago
It seems to be #c7c7c7.

Comment 5

6 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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....
tracking-firefox6: --- → ?
Keywords: regression
Summary: URL in the address bar unreadable (except for the domain part, of course) → URL in the address bar unreadable (except for the domain part, of course) due to insufficient contrast between the light gray and white
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?

Comment 10

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

Comment 11

6 years ago
(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)
tracking-firefox6: ? → +

Comment 12

6 years ago
Can we get UX to chime in here?
Summary: URL in the address bar unreadable (except for the domain part, of course) due to insufficient contrast between the light gray and white → domain highlighting lightens and de-emphasizes the rest of URL too much on Linux
I'd be happy to. Can anyone attach some screenshots of current look on Linux?
(Reporter)

Comment 14

6 years ago
Created attachment 536401 [details]
screenshot of Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110526 Firefox/7.0a1
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.
OS: Linux → All
Summary: domain highlighting lightens and de-emphasizes the rest of URL too much on Linux → domain highlighting lightens and de-emphasizes the rest of URL too much
Created attachment 536437 [details]
screenshot of Mozilla/5.0 (Mac; Intel) ... Gecko/20110530 Firefox/7.0a1
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".

Comment 20

6 years ago
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

6 years ago
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.
(Assignee)

Comment 22

6 years ago
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.
Attachment #538012 - Attachment is obsolete: true
(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?

Comment 26

6 years ago
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

6 years ago
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

6 years ago
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

6 years ago
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.
Keywords: access

Comment 31

6 years ago
(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.

Comment 33

6 years ago
(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.
(Assignee)

Comment 34

6 years ago
Created attachment 538860 [details] [diff] [review]
use text color at 60% opacity instead of graytext
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #538860 - Flags: review?(roc)
(Assignee)

Comment 35

6 years ago
Created attachment 538861 [details]
screenshot using 60% opacity
Attachment #538861 - Flags: ui-review?(limi)
(Assignee)

Updated

6 years ago
Blocks: 654809
(Assignee)

Updated

6 years ago
Attachment #538860 - Attachment description: use text color at 60% opacity → use text color at 60% opacity instead of graytext
Comment on attachment 538860 [details] [diff] [review]
use text color at 60% opacity instead of graytext

Review of attachment 538860 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #538860 - Flags: review?(roc) → review+
(Assignee)

Comment 37

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

Comment 38

6 years ago
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
(Assignee)

Updated

6 years ago
Attachment #538861 - Attachment description: screenshot → screenshot using 60% opacity
(Assignee)

Comment 39

6 years ago
Created attachment 538872 [details]
screenshot using 50% opacity
Attachment #538872 - Flags: ui-review?(limi)
(Assignee)

Updated

6 years ago
Attachment #538872 - Flags: ui-review?(limi) → ui-review?(faaborg)
(Assignee)

Updated

6 years ago
Attachment #538861 - Flags: ui-review?(limi) → ui-review?(faaborg)
Attachment #538872 - Flags: ui-review?(faaborg) → ui-review+
Attachment #538861 - Flags: ui-review?(faaborg) → ui-review-
(Assignee)

Comment 40

6 years ago
http://hg.mozilla.org/mozilla-central/rev/306bdc7101c3
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
(Assignee)

Updated

6 years ago
Attachment #538860 - Flags: approval-mozilla-aurora?
status-firefox6: --- → affected
(Assignee)

Comment 41

6 years ago
Created attachment 540304 [details] [diff] [review]
use text color at 50% opacity instead of graytext
Attachment #538860 - Attachment is obsolete: true
Attachment #538860 - Flags: approval-mozilla-aurora?
Attachment #540304 - Flags: approval-mozilla-aurora?

Comment 42

6 years ago
Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110621 Firefox/7.0a1
Status: RESOLVED → VERIFIED
Attachment #540304 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 43

6 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/c64b52363a1b
status-firefox6: affected → fixed
Hardware: x86_64 → All

Comment 44

6 years ago
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.

Comment 46

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

No, but I would welcome one.

Updated

5 years ago
Blocks: 680648

Updated

5 years ago
Blocks: 683811

Comment 47

5 years ago
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.
You need to log in before you can comment on or make changes to this bug.