797040 - form text input/textarea fields lose borders when CSS "border-style:solid" is set and "allow pages to choose their own colors" is unticked in preferences

Status: RESOLVED DUPLICATE of bug 452800

(Core :: CSS Parsing and Computation, defect)

Description

[Steve Horan]

Attachment: test case HTML. untick "allow pages to choose their own colors" to highlight bug

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

I set my Windows XP color scheme to classic, high contrast (white on black), and configured firefox color preferences to always use my own colors (preferences -> content -> colors -> untick "Allow pages to choose their own colors..."

Then visited a page that sets the css "border" attribute for text input/textarea fields. I have included a test case, but the problem can be readily seen in the wild at http://ebay.com/ (the search field)


Actual results:

Text input and textarea fields without a CSS border/border-style/border-color attribute set have a visible white border.

The same fields, when the CSS border attribute is set, lose their borders.


Expected results:

The color of the CSS-styled text field should not change/should remain visible. Referring to the ff_border_bug-disallow_colors.png screenshot, the "bar" text field should retain a border of the same color as the "foo" field above.

This bug is not present in Firefox 11.0, but is present in 12.0b1 and is still present in 15.0.1.

Comment 1

[Steve Horan]

Attachment: Screenshot of test.html when preferences, content, colors, "allow pages to choose their own colors" is unticked

Comment 2

[Steve Horan]

Attachment: Screenshot of test.html when preferences, content, colors, "allow pages to choose their own colors" is ticked

Comment 3

[Boris Zbarsky [:bzbarsky]]

Steve, are you willing to use http://harthur.github.com/mozregression/ to find when the bug first appeared?

Comment 4

[Steve Horan]

(In reply to Boris Zbarsky (:bz) from comment #3)
> Steve, are you willing to use http://harthur.github.com/mozregression/ to
> find when the bug first appeared?

Sure. Doing so now. Will report back soon.

Comment 5

[Steve Horan]

(In reply to Boris Zbarsky (:bz) from comment #3)
> Steve, are you willing to use http://harthur.github.com/mozregression/ to
> find when the bug first appeared?

Narrowed it with mozregression.

2011-12-22 = good
2011-12-23 = bad

Hope this helps. Let me know if you'd like me to do any further testing.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Thanks.  Given that, almost certainly a change from bug 700221.

The pages linked here change the border-style and border-width, so should drop native theming after the patch from bug 700221.

Steve, if you just take an input and style it with "-moz-appearance: none" but no other styles, does that also make the white border disappear for you?

Comment 7

[Steve Horan]

(In reply to Boris Zbarsky (:bz) from comment #6)
> Steve, if you just take an input and style it with "-moz-appearance: none"
> but no other styles, does that also make the white border disappear for you?

Kind of. The field retains a border, but it's different to the consistent white border. I tested on both my current working browser (11.0) and the 2011-12-23 bad nightly, and both exhibit the same style change for the -moz-appearance styling.

I'll attach a screenshot. The "baz" text input field is the one stled with moz-appearance: none

Comment 8

[Steve Horan]

Attachment: Screengrab showing how -moz-appearance: none affects text input field styling

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hmm.  So that's not the same rendering as the one in the first screenshot attached here...  I wonder why not.  It should be the same.  :(

Comment 10

[Steve Horan]

:( indeed. Just to clarify, are you saying that "-moz-appearance: none" should result in the text input field adopting the default, unstyled appearance like the "foo" example, or the borderless "bar" example?

Also, just a thought, which may or may not be helpful. The "bar" example that has no visible border, I'm not sure if it's got no border, or a black and thus invisible border. I did try and check for this by setting the main page background to blue, but that didn't change the background of the text field itself which remained black, so I wasn't really able to tell.

It's bed time in my timezone. If there are any further things you'd like me to test, feel free to leave as many as you like and I'll get to them when I wake up. Thanks for helping track this bug down, it's very appreciated.

Comment 11

[Boris Zbarsky [:bzbarsky]]

"-moz-appearance: none" should result in neither one.  It should result in us falling back to rendering using the CSS rules from forms.css.

But the "bar" example should be rendering that way too, and in particular with a visible border...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Steve, two more things to test.

1) If you have this:

  <span style="color: ThreeDFace">Some text</span>

and allow pages to use their own colors, what color does that text come out with in your high-contrast theme?

2) If you have:

    <input style="-moz-appearance: none; border-style: solid; border-width: 2px">

what does the resulting rendering look like?

Comment 13

[Steve Horan]

Hi. Tested those two things on both 11.0 and the first bad nightly, and they both render that HTML code the same.

With allow pages to choose their own colors ticked, neither the span or the input have a visible border, and the text of the span is invisible/black.

With allow pages to choose unticked, both still have no border but the span text is visible and uses my standard text color.

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK.  Then that's what's going on here.  Your OS color scheme seems to set "ThreeDFace" to black.  That's the system color we use for the input border when not doing native theming.  In the "-moz-appearance:none" case without "border-style: solid", the color adjustments that the default "border-style: inset" makes keep the border visible, but if the border-style is set to "solid", the border just becomes a flat ThreeDFace, which in your case is black...

So presumably either it's a bug on our end (asking for the wrong system color for ThreeDFace, or using the wrong system color name for borders), or in the OS theme in question...

David, any idea who'd know this sort of thing about Windows system fonts?

Comment 15

[Boris Zbarsky [:bzbarsky]]

Looks like what we ask for from the OS here is COLOR_3DFACE, which http://msdn.microsoft.com/en-us/library/windows/desktop/ms724371%28v=vs.85%29.aspx defines as:

  Face color for three-dimensional display elements and for dialog box backgrounds.

Which makes sense with "border-style: inset", but not with solid.

I wonder whether it would make sense to do one of two things:

1)  Disallow pages from changing border-style when they can't change colors.
2)  Use "border-style: solid" on inputs, but manually set the border colors in forms.css
    to ThreeDShadow and ThreeeDHighlight to simulate inset.  In theory, this is closer to
    how inset should be handled with system colors anyway...

Steve, I would highly recommend for now putting a rule implementing #2 above in your user stylesheet and updating to a current Firefox release.  Firefox 11 has a number of known security vulnerabilities, and you really shouldn't be using it on the open web...

Comment 16

[Steve Horan]

Thanks for the update.

I vote for ignoring border changes on form inputs/textareas/dropdowns when "allow pages to choose their own colors" is unticked.

Thanks for the user css suggestion. I'll look into that.

Thanks again for getting onto this for me. Happy to try out any more tests/nightlies as you proceed, and feel free to ask me anything should you want input from an accessibility perspective, as I appreciate that "the right way to do things" is less straightforward in that context.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Ignoring things only on particular elements is actually pretty hard.  Styles are shared across elements, so at the point when we're doing things like "figure out the border style" we don't actually know what set of elements we're working with, and it can include both form controls and regular divs.... So we'd need to either shut off border-style changes for all elements, or allow them for all elements.  :(

Comment 18

[Steve Horan]

Ah, okay. I think I assumed something different was going on with input fields becaues borders for divs and other elements seem to be working fine, but I imagine that's got something to do with FF rendering vs. native OS widget rendering.

I'd rather not see border style changes completely ignored when "allow pages to choose their own colors" is unticked, as I do make use of the dotted border style to outline some divs.

If I'm understanding the second option of doing it via forms.css sounds like it should suffice. Would this mean that when a page author changes the border style, I would continue to get the plain solid white border, or would this mean in those cases I'd get an inset style border, like the "baz" example i nthe screengrab showing -moz-appearance: none?

My preference is for consistent solid white, which is the behavior in 11.0, but I can definitely cope if that's impractical and the 3D inset style is what I'll get.

Comment 19

[Boris Zbarsky [:bzbarsky]]

If we did the forms.css thing then when the page styles the border you'd get the 3d inset style...  That's the default style we use when not doing native OS widget rendering.

Again, though, you can use userContent.css to override any and all of this to whatever you prefer.  That's obviously not a solution for average users, of course.  :(

Comment 20

[:Gijs (he/him)]

I believe this is a duplicate of bug 452800 which was fixed in Firefox 42.