197335 - Fix up aqua HTML form buttons

Status: RESOLVED DUPLICATE of bug 197094

(Core :: Layout: Form Controls, defect)

Description

[Brian Ryner (not reading)]

This bug tracks a few problems with the aqua HTML button implementation:

- buttons should not have an inner focus outline
- we need to add back in the hack to not draw the focus outlines on jaguar
because of the ugly lines through the buttons

Comment 1

[Asa Dotzler [:asa]]

bryner, any chance the "hack to not draw focus outline" will land in time for 1.4a?

Comment 2

[Asa Dotzler [:asa]]

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

Comment 3

[Brian Ryner (not reading)]

Attachment: patch

This fixes:

- the lines through buttons, by disabling the focus outline
- too much padding on buttons
- adds some margin for buttons

Comment 4

[Brian Ryner (not reading)]

Attachment: patch

this one fixes some problems with disabled buttons

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Hmm.. doesn't this make buttons and text inputs different heights?  See comment
at
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/forms.css#82

As long as the testcase at
http://web.mit.edu/bzbarsky/www/testcases/form-baseline/textInputInRunningText.
html looks fine with this patch (text inputs, file inputs, buttons all the same
height), sr=bzbarsky.

Comment 6

[Brian Ryner (not reading)]

I'm getting a 404 on that URL.  I also don't understand why these elements all
need to be the same height.  What does that accomplish?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Um.  I wonder why
http://web.mit.edu/bzbarsky/www/testcases/form-baseline/textInputInRunningText.html
got line-broken....

What it accomplishes is consistency.  More importantly, it accomplishes
non-broken rendering of <input type="file">, since the code for that assumes
that buttons and text inputs are the same height (if they are not, file inputs
look ugly and act broken).

In the end, all that matters is that the controls look good.  You could run
through the testcases in
http://web.mit.edu/bzbarsky/www/testcases/form-baseline/ in general to see how
your css reacts to various things people do to form controls.... (though those
testcases focus on textboxes).

Comment 8

[Brian Ryner (not reading)]

Couldn't you use top/bottom margin to pad out shorter elements to the height of
a larger element, rather than ensuring that border+padding are the same, as the
comment says?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Possibly.  I don't think I considered trying that.... Note that imo it _does_
look better with the form controls a consitent height, but again, I don't know
what it looks like on Mac.

Comment 10

[Simon Fraser [no longer active]]

On
<http://web.mit.edu/bzbarsky/www/testcases/form-baseline/textInputInRunningText-quirk.html>i
if I click any of the "BuTtoN" buttons next the the input, then the browser
button next to it grows larger eaach time. This doesn't happen with non-native
controls.

Comment 11

[Simon Fraser [no longer active]]

Hrm, it's a bit worse than that. If one of the buttons has focus, and reflow
happens (e.g. window resize) then buttons grow and grow.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yep.  That's one symptom of letting the heights be different, if I recall.

Of course the same issue could be caused by other problems too (eg bugs in
button reflow).....

Comment 13

[Ari]

I don't see the ugly lines through buttons other than kThemePushButton on
Jaguar. Why can't we draw the focus outline around every kind of button except
for that one?

Also, you might want to incorperate the stuff in the patch attached to bug
197094. (there is some overlap with this patch)

Comment 14

[Brian Ryner (not reading)]

I'll merge them together and fix it to only suppress the focus border for
pushbuttons.  Thanks for the info.

Comment 15

[Brian Ryner (not reading)]

*** This bug has been marked as a duplicate of 197094 ***