284041 - classic theme: gray-on-gray scrollbar color, not enough contrast to see where you are

Status: RESOLVED EXPIRED

(SeaMonkey :: Themes, defect)

Description

[Rick Stockton]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050224
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050224

My first use of "classic" theme, as my favorite mozdev themes are not yet
functional with 1.8b1 or 1.8b2 nightly. Scrollbars (for 'preferences', the
mailnews 'accounts/folders' panel, as well as web pages) are gray on gray. I can
hardly see ANY difference between the two colors.

In searching for duplicates, I saw an earlier bug, "I can't tell which tab is
active". In the version I'm running, the active Tab is shown with a much lighter
background than the inactive tabs. I don't much care whether you use the LIGHTER
 color (or shade of gray) to indicate the portion of the web page (or email
messages list, or etc.) which IS in view, with a darker background (like old
MOTIF) or whether you reverse and use the DARK color to indicate the visible
portion (like KDE Keramik).

But we need to have DIFFERENT colors or shades of gray.

Reproducible: Always

Steps to Reproduce:
1. Select "Classic" Theme in preferences.
2. Restart Mozilla.
3. View a web page with many lines, causing the vertical scrollbar to appear.
4. Note the difficulty in seeing the contrasting "color block" which represents
the portion of the page which is currently being viewed.
Actual Results:  
It's hard to see where I am (within the web page).

Expected Results:  
Presented the scrollbar and the 'currently in view' color block in different
colors, or in different shades of gray, to make the scrollbar more usable. I can
hardly see where to click it!

I don't consider this a "trivial" cosmetic problem, the usability of scrollbars
is badly compromised by the lack of contrast.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a GTK1 or GTK2 build?

Comment 2

[Rick Stockton]

My build ID is shown as a "1.8b2" because I pulled a trunk build immediately
after Asa's Mozillazine article said that 1.8b1 was done (pending just Release
Notes and etc.). The 1.8b1 directory had not yet been created on FTP.

My linux-i686-blah-blah-installer.tar.gz (which I unfortunately renamed), was
pulled on Feb 27 22:25 PST, with size 13503240 bytes. The filename said nothing
about GTK2 or XFT, I believe it to be the GTK1 version.

Boris, it would only take me 1 hour to save off my profile and try out both
versions of officially-released 1.8b1. My Mandrake 10.1 desktop has all
prerequisites. Would you like me to do this and report if GTK1 and GTK2 version
scrollbars both show the same appearance problem? Can do tomorrow, by
mid-afternoon PST.

Comment 3

[Rick Stockton]

Definitely "mozilla-i686-pc-linux-gnu-full-installer.tar.gz" of 27-Feb-2005 22:21.
Nightly Trunk, thus several days before builds which ultinately became 1.8b1.

Definitely NOT the gtk2+xft version.

Comment 4

[Rick Stockton]

Not sure why the build ID shows 20050224 instead of 20050227. My download time
is correct, so according to Tinderbox, I should have gotten lots of updates
subsequent to 20050224. Please advise what build(s) you'd like to see me
download and try.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Well, the difference between the two is that for GTK1 we set the colors and for
GTK2 the GTK theme sets the colors...  So for GTK1, this is our issue.

Comment 6

[Rick Stockton]

Hi again, Boris. OUR ISSUE.

GTK2+XFT Trunk Build from this morning (20050302, 9:04am) has good scrollbars. 
The "regular" (GTK1) full installer from earlier this evening, 5:11pm, still
suffers from the problem.

Bug 283863 looks like a probable Duplicate: although I can see the edges of the
slider, I have a VERY GOOD monitor, and the reporter of that bug may not have
looked as closely.

And I forgot the term "slider" when I searched for Duplicates :-(

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.