Closed Bug 409974 Opened 12 years ago Closed 12 years ago

Addresses in autocomplete list hard to read or invisible on certain systems


(Firefox :: Theme, defect, P2)




Firefox 3


(Reporter: jwbaker, Assigned: dao)




(Keywords: access, regression)


(6 files, 2 obsolete files)

Attached image Screenshot
The location bar autocomplete always uses black type for the title and green type for the URL on nonhighlighted entries, regardless of the platform look and feel.  See attached screenshot for why this is a bad idea.
Blocks: 399664
Depends on: 406215
Flags: blocking-firefox3?
Keywords: access
Do you know that there are platform colors that exist with these semantics?

We all know it's not ideal, but it seems to be the only sane option unless you want to make a complete move to non-native colors.
I don't know if there are platform semantics for this, but the main issue is we can't hard-wire foreground colors while using the platform background colors.
Duplicate of this bug: 414241
Please don't use gray text, people who use a dark theme like me to not hurt his/her eyes won't see anything.
(In reply to comment #5)
> Please don't use gray text, people who use a dark theme like me to not hurt
> his/her eyes won't see anything.

Note that GrayText doesn't literally mean "gray text" but the color your OS's theme uses to indicate a disabled item. Should that color not be readable, then it'd be the OS theme's issue.

Besides: See Dão's attachment 294887 [details] for how this might look with platform colors (though I hope to see the bold/underline used to indicated the matched text replaced with HighlightText/Highlight to fix bug 406254 as well).
Blocks: 393508
This does not block the final release of Firefox 3.
Flags: blocking-firefox3? → blocking-firefox3-
I suppose the summary wasn't quite clear. I.e., it sounded like a modest enhancement request rather than a description of a broken feature. Adjusting summary and re-requesting blocking.
Flags: blocking-firefox3- → blocking-firefox3?
Keywords: regression
Summary: Use platform colors in autocomplete list → Addresses in autocomplete list hard to read or invisible on certain systems
OS: Linux → All
Hardware: PC → All
No longer depends on: 406215
Component: Location Bar and Autocomplete → Theme
QA Contact: → theme
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
Assignee: nobody → faaborg
We are not supporting third party OS themes on windows and OS X, however on linux where there is a much wider range of OS themes, perhaps we should consider using an extracted system color.
(In reply to comment #9)
> We are not supporting third party OS themes on windows

We always did, and that's actually what "native" means. As mentioned in another bug, dropping this is also bad for forward compatibility.
Alex, this isn't about third party OS themes.  Stuff like the High Contrast themes will break hard on this.
Whiteboard: [needs status update]
>Stuff like the High Contrast themes will break hard on this.

Yes, our options for supporting high contrast themes are to select colors that look as good on black as they do on white, or to hard code the background of the results as well.  I should note that the rationale for the use of color in the results is not just aesthetic, but to help users process the results and scan just the URLs, or just the titles (  We can get this same effect and support high contrast themes by using a disabled text color, but that reopens the grey URL locationbar^2 debate.
XP and Vista both have four high contrast themes, three of them black and one of them white.  So if we hard code the background of the window to preserve contrast on results, we aren't breaking high contrast support but 3/4's of high contrast support.
Grey URL is the way to go. Hard-coding colors is not.

Hard-coded colors should be ripped off from Firefox, not added to it...
IMHO all chrome colors whatsoever, plus the default content background and foreground, should be themable. Set them in the default theme, whether by copying some OS-defined colors or by hardcoding them I don't care, but make sure that all elements have the necessary CLASSes and IDs to make CSS handling easy, and also try not to break existing Firefox themes (by which I mean: retain the Fx2 elements, classes and IDs if at all possible).

As for grey URL... I'm not convinced... yet.
There are now several bugs that are discussing using hard coded colors to create the best default theme, vs. only using extracted colors to support alternate OS themes.  I've asked beltzner and mconnor to weigh in on which approach we should take.
Bugs 409974 and 423718 are both blocking+, yet they both want to change the
color of URLs in the location bar autocomplete results.  To resolve the issue,
I've filed bug 425598 – All hard coded colors need to fall back to system
colors for accessibility.
How about using the link colour specified by the user in Preferences → Content → Colours – i.e. typically purple? That way, at least the user would be able to change the colour manually if it conflicted too horribly.

If the main text and background were also to use the colours chosen here, they should be less likely to clash in the first place.

(And I suppose in future, Firefox might be able to pick up on a preferred link colour from the OS; I know KDE has them (but then they have prefs for everything).)
Keywords: uiwanted
Whiteboard: [needs status update] → [has patch][needs status update]
>use native graytext color on Windows and Linux

We would like to solve this issue with bug 425598, falling back to grey text as you do in your patch addresses the problem, but doesn't resolve bug 423718, which is also blocking+
Well, graytext is a native platform color, so I don't see a conflict with bug 423718.
I don't see anyone working on a patch in bug 425598, and frankly I don't think it should block the release. Anyway, we should use the color that works now, and we can use any other color once that works.
Sure, but bug 425598 is blocking+ as well, I'm just trying to make sure we aren't going through unneeded extra revisions since we are starting to run out of time.
removing uiwanted since the intended approach seems to be pretty well specified.
Keywords: uiwanted
Attached patch Linux patch (obsolete) — Splinter Review
Attachment #312782 - Attachment is obsolete: true
Attachment #313387 - Flags: ui-review?(faaborg)
ooops, the last one was messed up.
Attachment #313387 - Attachment is obsolete: true
Attachment #313387 - Flags: ui-review?(faaborg)
Attachment #313390 - Flags: ui-review?(faaborg)
Comment on attachment 313390 [details] [diff] [review]
Linux patch (checked in)

Works for now given the wide range of Linux themes.  I don't know what the full set of potentially extracted system colors is on Linux, but it might be better to switch to something else in the future. For instance in bug 426732 someone mentions link-color in GTK 2.10
Attachment #313390 - Flags: ui-review?(faaborg) → ui-review+
(In reply to comment #26)
> it might be better
> to switch to something else in the future. For instance in bug 426732 someone
> mentions link-color in GTK 2.10

Absolutely. But at the moment there's no better already-exposed color than grayText, as far as I know.
Attachment #313390 - Flags: review?(
Whiteboard: [has patch][needs status update] → [has patch][needs review gavin][needs status update]
Duplicate of this bug: 426859
Reassigning to Dao since he wrote the patch.
Assignee: faaborg → dao
Attachment #313390 - Flags: review?( → review+
Whiteboard: [has patch][needs review gavin][needs status update] → [has patch][needs status update]
Keywords: checkin-needed
Depends on: 423718
No longer depends on: 425598
Does this mean this bug is fixed?

Checking in browser/themes/gnomestripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/gnomestripe/browser/browser.css,v  <--  browser.css
new revision: 1.205; previous revision: 1.204
Checking in toolkit/themes/gnomestripe/global/autocomplete.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/global/autocomplete.css,v  <--  autocomplete.css
new revision: 1.22; previous revision: 1.21
Keywords: checkin-needed
Whiteboard: [has patch][needs status update] → [needs status update]
Target Milestone: --- → Firefox 3
Whiteboard: [needs status update] → [needs status update][Linux fixed]
Attachment #313390 - Attachment description: Linux patch → Linux patch (checked in)
This is by no way fixed in Linux. See the screenshot I attach below.

I think bug 423263 should be set as a blocker of this one, since that's the dealing with native auto-completion colors extraction on Linux.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040914 Minefield/3.0pre

With theme:
(In reply to comment #32)
> Created an attachment (id=314707) [details]


Regardless of what's up with bug 423263, we're currently using -moz-appearance:menupopup, and GreyText should definitely be readable there. Please report this bug to the theme author.
Unfortunately this is not very readable with Ubuntu 8.04 default settings.
Here's what I've put in my userChrome.css to get the old appearance if anyone is interested:
.ac-url-text {
    color: #336633 !important;
.autocomplete-richlistitem {
    border-bottom: 1px solid ThreeDShadow !important;
This works on Windows:

color: GrayText !important;

.ac-url-text[selected="true"] {
 color: inherit !important;

Do we need to address this on Mac as well? I don't think so ...
Whiteboard: [needs status update][Linux fixed] → [windows fix in comment 35][Linux fixed]
Attached patch Windows patchSplinter Review
No, nothing to do for Mac here.
Attachment #315282 - Flags: review?(
Blocks: 423718
No longer depends on: 423718
Attachment #315282 - Flags: review?( → review+
Attachment #315282 - Flags: approval1.9?
Comment on attachment 315282 [details] [diff] [review]
Windows patch

Yeah, this seems easier than the way I did it.

One note: this doesn't take effect immediately when the theme changes - the user needs to restart Firefox to see the difference.
Attachment #315282 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
mozilla/browser/themes/winstripe/browser/browser.css 	1.199
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [windows fix in comment 35][Linux fixed]
I'm reopening this bug per comment #34 -- attachment 315166 [details].

I'm not sure why there haven't been bugs filed about making the url color darker on linux, but there's bugs like bug 432757 for vista to make the link darker on vista when it's already darker than the one for linux.

I'm not personally affected too much by the current GrayText because I only use linux in the computer labs. Maybe also linux users generally know how to change font colors or override things with userChrome.css. But I'm sure most EeePC users won't be as clever.

Linux themers: Do you stick with GrayText for the location bar url color?
OS: All → Linux
Resolution: FIXED → ---
beltzner: The url shows the effective gray colors of each platform's url text color. The first number is the HSB's brightness value.

65: #a7a7a7 Linux (GrayText)
65: #a6a6a6 Windows Old Not Default Theme (GrayText)
46: #767676 Windows Vista Old (#0066cc)
41: #696969 Windows Vista New (#0055bb)
40: #676767 OS X (#144fae)
36: #5b5b5b Old Green All Platform (#336633)
35: #595959 Windows XP (#006600)

In bug 432757, you made vista's link color go from brightness 46 to 41 -- both are already much darker than linux's graytext (as well the old not-default-theme url color on windows).
We're done here. Users who find grayText hard to read can change their OS theme. There's no other solution without bug 426732. As for using the native hyperlink color once it's available, please file a new bug.
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
I believe we chose GrayText on Windows because that way we could be sure it would react properly in high contrast theme scenarios, but that doesn't seem to be appropriate on Linux.

I'd recommend we use #696969 as the default on Linux, and leave Windows non-default theme the way it is.
Though I agree with Dao - this doesn't feel like a blocker to me, and I'd rather stay system native so that we're picking up colours off of the theme.
So for the record, how would you go about changing the color of GrayText in say.. Ubuntu/GNOME? I searched around and fiddled with themes for a good 20 minutes and haven't found anything useful. You can change window toolbar colors and styles and menu stuff.. but not a particular color name's color.. ?

I couldn't find anything about changing the color of disabled text. (Showing urls with disabled text isn't the only solution. On windows, the non-default-theme color for urls is black.)
You wouldn't customize the color but rather pick another OS theme. Or report to the theme author that you find GrayText hard to read...
Oh, that makes so much more sense now. It just turns out Clearlooks, the default GNOME theme, has a really light GrayText. Switching to Bluecurve or basically anything else makes the location bar urls readable.

I suppose somebody should be contacted about the default GNOME theme.. at least if they want people to be able to read location bar urls in Firefox 3 without needing to change anything.

Probably wouldn't help with existing systems though. (This computer lab has GNOME 2.16.0 distributed by Red Hat with a build date of 09/04/2006.)
Why not just take the default color used right above and use |opacity: 0.9;| or something?  Works with all themes and shouldn't lighten it too much
(In reply to comment #49)
> Why not just take the default color used right above and use |opacity: 0.9;| or
> something?  Works with all themes and shouldn't lighten it too much

I think you are right. GrayText does not work well with most of the default themes used by Linux distributions today and at least in the next 6 month.
I know that transparency screws up sub-pixel text rendering on Win XP at least. Also, it wouldn't be particularly good for accessible themes such as the high-contrast ones on Windows. I think we should live with graytext for now and hope for bug 426732 getting fixed soon.
High contrast themes like the white on black ones? The white would just become grayish with the opacity. I suppose making it lighter defeats the point of high contrast though..
This problem is quite audible with Clearlooks (the default Gnome theme) and is in no way fixed. Bug 426732 (making the native URL color available) seems to have a patch attached that awaits review. Perhaps this could be fixed for real before 3.0 ? Having the URLs in the autocomplete list almost unreadable on (most?) Gnome systems seems like a big problem to me.
Duplicate of this bug: 437358
Duplicate of this bug: 437887
Depends on: 430259
You need to log in before you can comment on or make changes to this bug.