171214 - Form buttons appear too high relative to text fields

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Nathan Silva]

In forms, when a submit or other button is used, it appears high off the
baseline compared with text fields. This makes some forms look strange.

This happened sometime after 20020923.

Comment 1

[Nathan Silva]

Attachment: Picture of buttons in various builds

Comment 2

[Jason Bassford]

This may be related to bug 171186 - which mentions other form controls also. 
I'm not sure if it's a duplicate or not...

Comment 3

[John Keiser (jkeiser)]

Yes, this is a deliberate regression of bug 167236.  We need to find a way to
align buttons with only one line (at the least).

I assume you are using <button> and not <input type=button>?

Comment 4

[John Keiser (jkeiser)]

Actually, do me a favor and upload your testcase please :)

Comment 5

[Nathan Silva]

Attachment: Test case

Here is the test case.

Comment 6

[John Keiser (jkeiser)]

Ah, I see.  IE's solution, which is probably what we should do, is to change the
padding so that this generally doesn't look bad.  Note that at least on WinXP
the button is only a couple of pixels off.

Comment 7

[John Keiser (jkeiser)]

Oh ... that's not the problem.  The problem is that input type=button is not
aligned to baseline properly.  This should have been fixed by the bug 167236
patch and was not fixed right.

Comment 8

[John Keiser (jkeiser)]

Oh ... that's not the problem.  The problem is that input type=button is not
aligned to baseline properly.  This should have been fixed by the bug 167236
patch and was not fixed right.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: fix

The other patch rotted a bit... we don't want to bottom-align
reset/button/submit _inputs_, just <button> elements for now.

Comment 10

[Boris Zbarsky [:bzbarsky]]

For the curious, the fix for bug 162573 is what caused trouble here.

Comment 11

[Nathan Silva]

Boris, your patch fixes the problem, but may I point out that the button is now
"correctly" aligned with the bottom of the text box, whereas in IE6 and previous
Mozilla it was about one pixel higher than the bottom of the text box. (see
earlier attachment)

Not sure if this is a problem -- how closely you want to match IE6's layout.

In any case, it sounds like you plan to come back to it later, and it's fine for
now.

Comment 12

[John Keiser (jkeiser)]

Comment on attachment 100951 [details] [diff] [review]
fix

r=jkeiser
Happy happy joy joy

Comment 13

[John Keiser (jkeiser)]

We do not have to be exactly the same as IE's layout.  We just have to be sane
and close enough that reasonable people (or unreasonably important people) don't
yell at us.  What you found was definitely an insane behavior; one pixel off
IE's layout (and in a very sane way such that heights are the same) is not :)

Comment 14

[Nathan Silva]

Yeah, it's a good thing. With this patch buttons look better in Mozilla than
IE6. I only mentioned it in case there was some plan to match IE's layout. I
know Mozilla isn't trying to copy IE, but there are certain things in the past
where it's mattered. Rock on!

Comment 15

[John Keiser (jkeiser)]

dbaron or rbs, could you sr?  This fixes the input type = button / text
alignment thing.

Comment 16

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

Comment on attachment 100951 [details] [diff] [review]
fix

sr=dbaron

Comment 17

[Boris Zbarsky [:bzbarsky]]

Nathan, we in fact had pretty much IE's layout before bug 167236 was fixed.  
We're working on improving on that.  ;)

Comment 18

[Antony Mawer]

Ah! I'd been looking for this bug. On http://www.google.com/ the buttons on
recent builds (eg. 20020926) are jammed right up underneath the search textbox.
Good to see a fix is already in hand! :)

Comment 19

[John Keiser (jkeiser)]

Fix checked in.

Comment 20

[Boris Zbarsky [:bzbarsky]]

OK.  I should have tested more thoroughly, but this fix introduced another
regression.  See the third part of the testcase at
http://web.mit.edu/bzbarsky/www/testcases/form-baseline/textInputInRunningText.html
and in particular the file input.  Note that it overlaps the text below it.  Try
clicking on it.  Much fun can be had this way....

Note that
http://web.mit.edu/bzbarsky/www/testcases/form-baseline/textInputInRunningText-quirk.html
does _not_ show the problem and also not that pre-bug-167236 the two testcases
were rendered differently.

Attaching patch that restores the status quo and I think we should get to the
bottom of why sizing of <input type="file"> is different in the two modes...

Comment 21

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed change, but please test and all that!

OK.  I ran this through the testcases at
http://web.mit.edu/bzbarsky/www/testcases/form-baseline/ and it seems happy. 
It does _not_ restore the status quo but rather "does the right thing" imo. 
I'm still mystified as to why the <input type="file"> rendered so differently
in the two modes... but with this change it should be happy, I _think_.

Comment 22

[Boris Zbarsky [:bzbarsky]]

In comment 20, paragraph 2 should say "also note that" instead of "also not that".

Comment 23

[John Keiser (jkeiser)]

bug 167236 backed out.

Comment 24

[Jason Bassford]

Look at the height of the "Change Forum Display" button on MozillaZine here:

http://www.mozillazine.org/talkback.html?article=2512

This is exactly what we were seeing before this bug was FIXED.  Other instances
have been corrected but not this one.

Is this covered by this bug (if so it should be reopened) or is it something
different (if so please point me to the bug)?

Comment 25

[John Keiser (jkeiser)]

That is bug 167236, and has been the case for time immemorial.