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

Status: RESOLVED FIXED

(Firefox :: Theme, defect, P2)

Description

[Jeffrey Baker]

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

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Do you know that there are platform colors that exist with these semantics?

Comment 2

[Dão Gottwald [:dao]]

GrayText.

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.

Comment 3

[Jeffrey Baker]

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.

Comment 5

[Andrés Delfino]

Please don't use gray text, people who use a dark theme like me to not hurt his/her eyes won't see anything.

Comment 6

[Simon Bünzli]

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

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

This does not block the final release of Firefox 3.

Comment 8

[Dão Gottwald [:dao]]

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.

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 10

[Dão Gottwald [:dao]]

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

Comment 11

[Mike Connor [:mconnor]]

Alex, this isn't about third party OS themes.  Stuff like the High Contrast themes will break hard on this.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

>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 (https://bugzilla.mozilla.org/attachment.cgi?id=289065).  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.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 14

[Andrés Delfino]

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

Comment 15

[Tony Mechelynck [:tonymec]]

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.

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 18

[Grey Nicholson (they/them)]

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

Comment 19

[Dão Gottwald [:dao]]

Attachment: use native graytext color on Windows and Linux

Comment 20

[Alex Faaborg [:faaborg] (Firefox UX)]

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

Comment 21

[Dão Gottwald [:dao]]

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.

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 23

[Alex Faaborg [:faaborg] (Firefox UX)]

removing uiwanted since the intended approach seems to be pretty well specified.

Comment 24

[Dão Gottwald [:dao]]

Attachment: Linux patch

Comment 25

[Dão Gottwald [:dao]]

Attachment: Linux patch (checked in)

ooops, the last one was messed up.

Comment 26

[Alex Faaborg [:faaborg] (Firefox UX)]

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

Comment 27

[Dão Gottwald [:dao]]

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

Comment 29

[Alex Faaborg [:faaborg] (Firefox UX)]

Reassigning to Dao since he wrote the patch.

Comment 30

[Reed Loden [:reed]]

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

Comment 31

[Andrés Delfino]

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.

Comment 32

[Andrés Delfino]

Attachment: Screenshot in Ubuntu 7.10.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040914 Minefield/3.0pre

With theme:
http://art.gnome.org/themes/gtk2/1285

Comment 33

[Dão Gottwald [:dao]]

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

> http://art.gnome.org/themes/gtk2/1285

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.

Comment 34

[Sylvain Pasche]

Attachment: Appearance with default Ubuntu 8.04 theme

Unfortunately this is not very readable with Ubuntu 8.04 default settings.

Comment 35

[Sylvain Pasche]

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;
}

Comment 36

[Mike Beltzner [:beltzner, not reading bugmail]]

This works on Windows:

.ac-url-text:not(:-moz-system-metric(windows-default-theme)){
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 ...

Comment 37

[Dão Gottwald [:dao]]

Attachment: Windows patch

No, nothing to do for Mac here.

Comment 38

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 39

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/themes/winstripe/browser/browser.css 	1.199

Comment 40

[Ed Lee :Mardak]

Attachment: screenshot of windows xp + royale theme

Comment 41

[Ed Lee :Mardak]

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?

Comment 42

[Ed Lee :Mardak]

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

Comment 43

[Dão Gottwald [:dao]]

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.

Comment 44

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 45

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 46

[Ed Lee :Mardak]

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

Comment 47

[Dão Gottwald [:dao]]

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

Comment 48

[Ed Lee :Mardak]

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

Comment 49

[Ian Spence]

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

Comment 50

[Michael Monreal [:micmon]]

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

Comment 51

[Dão Gottwald [:dao]]

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.

Comment 52

[Ed Lee :Mardak]

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

Comment 53

[Ivan Yosifov]

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.