187150 - text box bottom and right sides are faint / invisible

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Widget: Mac, defect, P4)

Description

[Tom Schneider]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016

I am typing this message into a text box on Mac OSX.  The right and bottom
sides of the box are nice and visible.  The lower and the right sides are
so faint as to be virtually invisible.

Reproducible: Always

Steps to Reproduce:
1. Run mozilla on OSX
2. Go to any page that has html text form input
3. look at the edges of the rectangle for the text input

Actual Results:  
lower and right sides are too faint to see.

Expected Results:  
Make the lower and right sides the same color as the upper and right.
Don't be fancy over being usable!

This is potentially quite confusing for new users!!
They won't recognize that there is a box there to type
into.  It is only unsettling for seasoned users.

Comment 1

[Christopher Hoess (gone)]

->Layout: Form Controls

Comment 2

[Vladimir Ermakov]

confirming

Comment 3

[Uri Bernstein]

*** Bug 275819 has been marked as a duplicate of this bug. ***

Comment 4

[Uri Bernstein]

Moving to "Widget: Mac" (is "GFX: Mac" more correct?)

Comment 5

[Uri Bernstein]

Here's my analysis of what's happening:

- The border is specified in forms.css as "2px inset ThreeDFace". (e.g.
http://lxr.mozilla.org/mozilla/source/layout/style/forms.css#83)

- ThreeDFace, for Mac, is translated to kThemeBrushButtonFaceActive
(http://lxr.mozilla.org/mozilla/source/widget/src/mac/nsLookAndFeel.cpp#258)

- This returns, for a default OS X settings: #f0f0f0.

- To produce the "inset" colors, this value is sent, together with the
background color, to NS_GetSpecial3DColors(). The results, for a white
background, are: #848484 (for the top and left borders) and #fafafa (for the
bottom and right borders).

#fafafa is not distinguishable to a typical human eye from #ffffff - so the left
and bottom borders seem missing.

A bit of experimenting shows that setting the "basic" border color (currently:
ThreeDFace) to any value between ~#808080 and ~#c0c0c0 gives a
reasonably-looking result.

The are several places along the way where this can be fixed. I suspect the most
correct solution would be to use something else than kThemeBrushButtonFaceActive
for ThreeDFace, but I'm not sure what that should be. This might also affect the
color of other elements, such as buttons.

Alternatively, we can have an appropreate hard-coded value for the border-color
in the CSS, instead of "ThreeDFace". This will have to be done in a mac-only
section, of course.

This is a very visually-disturbing bug, so I wonder if we can come up with a
simple solution that can be pushed for 1.8.

Comment 6

[Uri Bernstein]

Safari maps "ThreeDFace" to #c0c0c0 (very different than our #f0f0f0).

It also does a better job (IMO) of deriving colors for the "3d" effect: When I
try "border: 2px inset #f0f0f0", the actual colors I get are #787878 and #f0f0f0.

Comment 7

[Uri Bernstein]

Attachment: System colors in MacOS9/Moz0.9, Firefox, and Safari

This screenshot shows CSS system colors as rendered on (left to right):
1. Mozilla 0.9 (after bug 1004 was fixed!), running on Classic (OS 9)
emulation.
2. Modern-day Firefox (on OS X, of course)
3. Safari (ditto)

This shows that while the values returned by GetThemeBrushAsColor() for 3D
elements made sense back in the OS 8/9 days (when Mozilla started using them),
they probably no longer do on OS X, as demonstrated by the fact that Safari
chose to ignore them and use hard-coded values instead.

Comment 8

[Uri Bernstein]

Is this going to be fixed by moving to Cocoa widgets?
If not, can someone please comment on what's the best way to fix this, given the information in comment #5?

This bug really hurts my eyes on a daily basis.

Comment 9

[Uri Bernstein]

Attachment: patch

Hard-code CSS system colors to the values used by Safari (see comment #7).

Comment 10

[Uri Bernstein]

Comment on attachment 211151 [details] [diff] [review]
patch

This patch, as is, makes context menu items invisible (at least in SeaMonkey).
Still, I'd appreceate comments on what's the preferred way to fix this.

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Blocker+ for 1.8.1, but we need a branch-friendly patch ASAP.

(Josh, do you have an estimate for work here?)

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hardcoding the system colors doesn't seem like the best of ideas here; essentially it's regressing our support for CSS system colors.

Is the problem here really that these colors are designed for use against a gray background rather than a white one?  Should our HTML form controls instead be styled to avoid using such colors?

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(And note that pretty much the same problem exists for me on Linux.)

Comment 14

[Mike Schroepfer]

I'd love to see some improvements in look and feel on Mac.   Given comment 12 and the fact that this is not on the trunk I'm not sure it is going to make it for 1.8.1.

Josh/Beltzner is there any hope of getting improved mac form controls for FF2?

Comment 15

[Simon Fraser [no longer active]]

(In reply to comment #14)
> I'd love to see some improvements in look and feel on Mac.   Given comment 12
> and the fact that this is not on the trunk I'm not sure it is going to make it
> for 1.8.1.
> 
> Josh/Beltzner is there any hope of getting improved mac form controls for FF2?

There are some excellent 3rd party skinned form widgets (see, for example, <http://kmgerich.com/2006/03/11/mac-like-form-controls-for-firefox/>). Can we use one of those?

Comment 16

[Josh Aas]

I have already contacted kmgerich about putting together a patch for a new form widgets theme.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Such changes need careful review.  They need to be considered from two perspectives:
 * what they do to existing pages
 * how they respond to specific things that authors do (both when authors are testing with them and when authors or not).  For example, do we behave uniformly across platforms and interoperably with other browsers when an author specifies 'margin: 2px' to get a little extra space around a control?

I worry that the second one might not be getting enough consideration.

They also need significant testing from both perspectives:
 * are they compatible with existing pages?
 * are authors who style form controls getting unexpected results?
and to get particularly the second type of feedback I'm somewhat uncomfortable pushing such changes in this late.

Comment 18

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

Josh, where are we on this? The stauts whiteboard says dupeme, there's no patch, but I remember you showing me something about this earlier. As dbaron says, it's getting a little late for taking large changes, but I'd like to set a TM on this ...

Comment 19

[Josh Aas]

Bug 343216 is the bug for the form widget changes that would fix this. That is only one way of going about this, the way I showed to you last week. Its not looking good timing-wise.

Comment 20

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

Not going to block on this, but we'd take a baked patch from trunk if you can get us one in short order.