197094 - Various problems with new form widgets

Status: RESOLVED FIXED

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Neil Lee [:neilio]]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/BeatnikPad Chimera/0.6+
Build Identifier: Build ID: 2003031208

Now that aqua form widgets have landed (bug #188254), there's a bunch of small
(but notable) problems with form elements in Camino. Screen captures will be
attached demonstrating the problems I've seen so far.

1. textfields take on the background colour of the cell they're in
(Screencapture #1).
2. buttons get that "chopped-in-half" appearance after being clicked
(Screencapture #2).
3. With my personal site (http://www.beatnikpad.com/) the search button has a
dark-grey background and white text. Chimera would ignore any CSS styling and
display the button with black text on an aqua background, which made sense.

Now, Camino displays the button using the text-color, which makes the button
completely unreadable. Is it possible if we're going to use aqua buttons to just
ignore the text-color completely?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Neil Lee [:neilio]]

Attachment: Screencapture #1 (text fields and background colours)

Comment 2

[Neil Lee [:neilio]]

Attachment: Screencapture #2: "broken" button

Comment 3

[Neil Lee [:neilio]]

Attachment: Screencapture #3: text colour on button

Comment 4

[Neil Lee [:neilio]]

ARG. Sorry, screencaptures were at 300ppi. Reattaching more reasonable images.

Comment 5

[Neil Lee [:neilio]]

Attachment: Screencapture #1 (textfield background)

Comment 6

[Neil Lee [:neilio]]

Attachment: Screencapture #2: "broken" button

Comment 7

[Neil Lee [:neilio]]

Attachment: Screencapture #3: text-color on button

Comment 8

[Hanspeter Niederstrasser]

I can confirm examples #1 and #2.  Also, highlights in select elements with
multiple="multiple" are rendered incorrectly when one or more items are
selected.  See attached screencapture.

Comment 9

[Hanspeter Niederstrasser]

Attachment: Screencapture #4: select with multiple

Top select element has multiple="multiple".  Bottom select element does not
have multiple="multiple".

Comment 10

[Ari]

Attachment: patch

This should fix it. However, when I was looked at the form control code I saw
some other issues:

1. Although this patch fixes the problem with <select multiple>, <select
multiple size="1"> is not handled well because it produces a one line listbox.
It would probably be cooler if we had a dropdown with multiple checkmarks.

2. I think we a way in nsNativeThemeMac::GetMinimumWidgetSize to specify
whether the size is overidable on a per-dimension basis (e.g. just the width or
just the height) because many Aqua controls like buttons and dropdowns have a
fixed height but not a fixed width.

3. I'm not sure how to get rid of the dotted mozilla focus rectangle (as
opposed to the Aqua focus ring) on buttons and select listboxes.

Comment 11

[Greg K.]

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

Comment 12

[Greg K.]

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

Comment 13

[Ari]

Attachment: patch v2

Slightly better patch that fixes the <select size="0"> case in bug 182681

Comment 14

[Ari]

I figured out how to remove the dotted rectangle from buttons, but I still can't
figure out how to remove it from <option> elements in multi-line <select>s.
Another thing I'd like to do is get focus rectangles on textfields and
multi-line <select>s. The problem is, I don't know how to detect if they have focus.

Comment 15

[Asa Dotzler [:asa]]

see also bug 197335

Comment 16

[Asa Dotzler [:asa]]

see also bug 197335

Comment 17

[ender_mb]

Two more problems with the form buttons:
*they are about a pixel too tall, so they don't look rounded correctly on the sides
*when a button is clicked, its text moves to the right, Windows-esque; it should
stay put

Comment 18

[ender_mb]

Attachment: button screenshot

screenshot showing normal vs. clicked state, button size

Comment 19

[Brian Ryner (not reading)]

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

Comment 20

[Brian Ryner (not reading)]

Attachment: patch

Let's try this one.  I made sure that the button and textfield top and bottom
border+padding is the same, so as not to cause problems with file inputs.  I
went ahead and left the background as transparent and fixed the native theme
code to not disable -moz-appearance in that case.  (I do think we want to keep
those backgrounds as transparent so that Gecko doesn't waste time painting a
white background before we draw over it).  This also has the focus ring
disabling for pushbuttons to work around the lines through the buttons, and
fixes the moving text when buttons are pushed in.

Comment 21

[Brian Ryner (not reading)]

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

pink, does this look ok? also, ajfeldman if you could look over this that would
be great.

Comment 22

[Neil Lee [:neilio]]

I know it's mostly a cosmetic issue, but I hope this lands soon - is the delay
because you're waiting for permission to land these on the Mozilla trunk?

Comment 23

[Mike Pinkerton (not reading bugmail)]

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

+  static PRBool OnJaguar();

i could have sworn we already had this in gfx somewhere, maybe not. sucks we
can't share code with widget. yay com!

Comment 24

[Ari]

what about this stuff from the old patch?

 select[size] {
-  -moz-appearance: none;
+  -moz-appearance: listbox;
   margin: 0px;
   background-color: -moz-Field !important;
 }
 
+select[size="0"],
 select[size="1"] {
   -moz-appearance: menulist;
   margin: 1px;
   background-color: transparent !important;
 }
 
+select[multiple] {
+  -moz-appearance: listbox;
+  margin: 0px;
+  background-color: -moz-Field !important;
+}
+
 select > input[type="button"] {
   /* make sure nothing paints for the menulist button, since the button is
      painted as part of the menulist. */
@@ -96,10 +102,15 @@
   height: 14px;
 }
 
 button,
 input[type="reset"],
 input[type="button"],
 input[type="submit"] {
   -moz-appearance: button-small;
   font-size: 11px;
+  color: -moz-FieldText !important;
 }

Comment 25

[Avi Drissman]

Attachment: Problem with borders of text fields

Snapshots of pre- and post-1.3 landings, and their effect on text field
borders. Text field borders now don't have that Aqua look.

Comment 26

[Brian Ryner (not reading)]

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

Comment 27

[Brian Ryner (not reading)]

 select[size] {
-  -moz-appearance: none;
+  -moz-appearance: listbox;
   margin: 0px;
   background-color: -moz-Field !important;
 }

this one is in my tree now. Not sure why it's not in the patch.

+select[size="0"],
 select[size="1"] {
   -moz-appearance: menulist;
   margin: 1px;
   background-color: transparent !important;
 }
 
+select[multiple] {
+  -moz-appearance: listbox;
+  margin: 0px;
+  background-color: -moz-Field !important;
+}
+

I'd prefer to fix this separately.  It's not a regression from the 1.0 branch
behavior.


+  color: -moz-FieldText !important;

This one is tricky.  If it's !important then a page wouldn't be able to override
it, but in the case where the page uses a different background color we'll drop
the aqua appearance, and in that case we _do_ want to use the page-specified
text color.  I'll see if I can come up with a way to make that work.

Comment 28

[Ari]

In order to deal with the

+  color: -moz-FieldText !important;

issue I think we are going to need to come up with a consistent policy about how
much styling of form controls should be allowed as is being dicussed in bug
161261 and bug 198822. As far as I can tell, Safari allows absolutely none.

In any case, as it stands now, overriding the background color of a button
doesn't work anyway.

Comment 29

[Simon Fraser [no longer active]]

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

Comment 30

[Brian Ryner (not reading)]

Attachment: one more try

Ok, so it turns out dynamically disabling -moz-appearance for buttons has some
serious problems.  We really need a way to keep some of the style rules in
platform-forms.css from applying in that case.	I'm going to punt on that for
the moment so we can get some of these more basic problems addressed now.

This patch uses !important for the button text color, and there's no disabling
of -moz-apperance for buttons.

Comment 31

[Brian Ryner (not reading)]

Comment on attachment 119234 [details] [diff] [review]
one more try

carrying over r=pink, requesting sr.

btw, the makefile change here fixes a problem I found where libgfx_mac isn't
rebuilt when libgfxshared_s.a changes.

Comment 32

[Neil Lee [:neilio]]

I'm sorry if this isn't the proper place to be asking this, but with the aqua
form controls landing, does that mean that they should appear in the Mac OS X
build of Mozilla too?

Comment 33

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 119234 [details] [diff] [review]
one more try

sr=bzbarsky assuming:

1) The tests at http://web.mit.edu/bzbarsky/www/testcases/form-baseline/ look
pretty with this patch.  ;)

2)  Clicking on buttons gives visible feedback (or not, per platform
guidelines)

3)  Clicking on buttons does not shift text below the buttons

4)  Clicking on file input buttons doesn't act all weird.  ;)

Comment 34

[Brian Ryner (not reading)]

To answer Neil's question, no, not yet.  One thing that would need to happen
first is implementing a native popup for the select widget in Carbon.

Comment 35

[Simon Fraser [no longer active]]

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

Comment 36

[Brian Ryner (not reading)]

patch is checked in.

Comment 37

[Greg K.]

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

Comment 38

[Mark Mentovai]

The borders on <input type="text"> fields have been fixed, but the problem is
still present for <textarea> elements.  See comment 25.  Bug 200841 filed.

Markk