Various problems with new form widgets

RESOLVED FIXED

Status

Camino Graveyard
HTML Form Controls
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: neilio, Assigned: Brian Ryner (not reading))

Tracking

Details

(URL)

Attachments

(8 attachments, 5 obsolete attachments)

(Reporter)

Description

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

Comment 1

16 years ago
Created attachment 116993 [details]
Screencapture #1 (text fields and background colours)
(Reporter)

Comment 2

16 years ago
Created attachment 116994 [details]
Screencapture #2: "broken" button
(Reporter)

Comment 3

16 years ago
Created attachment 116995 [details]
Screencapture #3: text colour on button
(Reporter)

Updated

16 years ago
Attachment #116993 - Attachment is obsolete: true
(Reporter)

Updated

16 years ago
Attachment #116994 - Attachment is obsolete: true
(Reporter)

Updated

16 years ago
Attachment #116995 - Attachment is obsolete: true
(Reporter)

Comment 4

16 years ago
ARG. Sorry, screencaptures were at 300ppi. Reattaching more reasonable images.
(Reporter)

Comment 5

16 years ago
Created attachment 116996 [details]
Screencapture #1 (textfield background)
(Reporter)

Comment 6

16 years ago
Created attachment 116997 [details]
Screencapture #2: "broken" button
(Reporter)

Comment 7

16 years ago
Created attachment 116998 [details]
Screencapture #3: text-color on button
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.
Created attachment 117026 [details]
Screencapture #4: select with multiple

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

Updated

16 years ago
Summary: Various problems with new form elements → Various problems with new form widgets

Comment 10

16 years ago
Created attachment 117208 [details] [diff] [review]
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

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

Comment 12

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

Comment 13

16 years ago
Created attachment 117220 [details] [diff] [review]
patch v2

Slightly better patch that fixes the <select size="0"> case in bug 182681
Attachment #117208 - Attachment is obsolete: true

Comment 14

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

16 years ago
see also bug 197335

Comment 16

16 years ago
see also bug 197335
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 17

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

16 years ago
Created attachment 117517 [details]
button screenshot

screenshot showing normal vs. clicked state, button size
(Assignee)

Comment 19

16 years ago
*** Bug 197335 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 20

16 years ago
Created attachment 118176 [details] [diff] [review]
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.
(Assignee)

Comment 21

16 years ago
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.
Attachment #118176 - Flags: review?(pinkerton)
(Reporter)

Comment 22

16 years ago
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 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!
Attachment #118176 - Flags: review?(pinkerton) → review+

Comment 24

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

16 years ago
Created attachment 118770 [details]
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.
(Assignee)

Comment 26

16 years ago
*** Bug 198552 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 27

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

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

16 years ago
*** Bug 200073 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 30

16 years ago
Created attachment 119234 [details] [diff] [review]
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.
Attachment #118176 - Attachment is obsolete: true
(Assignee)

Comment 31

16 years ago
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.
Attachment #119234 - Flags: superreview?(bzbarsky)
Attachment #119234 - Flags: review+
(Reporter)

Comment 32

16 years ago
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 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.  ;)
Attachment #119234 - Flags: superreview?(bzbarsky) → superreview+
(Assignee)

Comment 34

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

16 years ago
*** Bug 162877 has been marked as a duplicate of this bug. ***
QA Contact: winnie → sairuh
(Assignee)

Comment 36

16 years ago
patch is checked in.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 37

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

Comment 38

16 years ago
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
You need to log in before you can comment on or make changes to this bug.