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

RESOLVED FIXED in Firefox 3

Status

()

Firefox
Theme
P2
normal
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: Jeffrey Baker, Assigned: dao)

Tracking

({access, regression})

Trunk
Firefox 3
All
Linux
access, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments, 2 obsolete attachments)

(Reporter)

Description

11 years ago
Created attachment 294666 [details]
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.

Updated

11 years ago
Blocks: 399664
(Assignee)

Updated

11 years ago
Depends on: 406215
Flags: blocking-firefox3?
Keywords: access
Do you know that there are platform colors that exist with these semantics?
(Assignee)

Comment 2

11 years ago
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.
(Reporter)

Comment 3

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

Updated

10 years ago
Duplicate of this bug: 414241

Comment 5

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

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

Updated

10 years ago
Blocks: 393508
This does not block the final release of Firefox 3.
Flags: blocking-firefox3? → blocking-firefox3-
(Assignee)

Comment 8

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

Updated

10 years ago
OS: Linux → All
Hardware: PC → All
(Assignee)

Updated

10 years ago
No longer depends on: 406215
(Assignee)

Updated

10 years ago
Component: Location Bar and Autocomplete → Theme
QA Contact: location.bar → theme
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2

Updated

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

Comment 10

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

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

Comment 19

10 years ago
Created attachment 312782 [details] [diff] [review]
use native graytext color on Windows and Linux
(Assignee)

Updated

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

Comment 21

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

Comment 24

10 years ago
Created attachment 313387 [details] [diff] [review]
Linux patch
Attachment #312782 - Attachment is obsolete: true
Attachment #313387 - Flags: ui-review?(faaborg)
(Assignee)

Comment 25

10 years ago
Created attachment 313390 [details] [diff] [review]
Linux patch (checked in)

ooops, the last one was messed up.
Attachment #313387 - Attachment is obsolete: true
Attachment #313387 - Flags: ui-review?(faaborg)
(Assignee)

Updated

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

Comment 27

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

Updated

10 years ago
Attachment #313390 - Flags: review?(gavin.sharp)
(Assignee)

Updated

10 years ago
Whiteboard: [has patch][needs status update] → [has patch][needs review gavin][needs status update]

Updated

10 years ago
Duplicate of this bug: 426859
Reassigning to Dao since he wrote the patch.
Assignee: faaborg → dao
Attachment #313390 - Flags: review?(gavin.sharp) → review+
Whiteboard: [has patch][needs review gavin][needs status update] → [has patch][needs status update]
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
(Assignee)

Updated

10 years ago
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
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
Status: NEW → ASSIGNED
Keywords: checkin-needed
Whiteboard: [has patch][needs status update] → [needs status update]
Target Milestone: --- → Firefox 3
(Assignee)

Updated

10 years ago
Whiteboard: [needs status update] → [needs status update][Linux fixed]
(Assignee)

Updated

10 years ago
Attachment #313390 - Attachment description: Linux patch → Linux patch (checked in)

Comment 31

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

10 years ago
Created attachment 314707 [details]
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
(Assignee)

Comment 33

10 years ago
(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

10 years ago
Created attachment 315166 [details]
Appearance with default Ubuntu 8.04 theme

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

Comment 35

10 years ago
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:

.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 ...
Whiteboard: [needs status update][Linux fixed] → [windows fix in comment 35][Linux fixed]
(Assignee)

Comment 37

10 years ago
Created attachment 315282 [details] [diff] [review]
Windows patch

No, nothing to do for Mac here.
Attachment #315282 - Flags: review?(gavin.sharp)
(Assignee)

Updated

10 years ago
Blocks: 423718
No longer depends on: 423718
Attachment #315282 - Flags: review?(gavin.sharp) → 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+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
mozilla/browser/themes/winstripe/browser/browser.css 	1.199
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [windows fix in comment 35][Linux fixed]

Comment 40

10 years ago
Created attachment 317108 [details]
screenshot of windows xp + royale theme

Comment 41

10 years ago
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?
Status: RESOLVED → REOPENED
OS: All → Linux
Resolution: FIXED → ---

Comment 42

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

Comment 43

10 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 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.

Comment 46

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

Comment 47

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

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

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

Comment 51

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

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

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

Updated

10 years ago
Duplicate of this bug: 437358

Updated

10 years ago
Duplicate of this bug: 437887
Depends on: 430259

Updated

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