Form buttons appear too high relative to text fields

RESOLVED FIXED

Status

()

RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: nathans, Assigned: john)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

16 years ago
Created attachment 100891 [details]
Picture of buttons in various builds

Comment 2

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

Comment 3

16 years ago
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>?
Depends on: 167236
(Assignee)

Comment 4

16 years ago
Actually, do me a favor and upload your testcase please :)
(Reporter)

Comment 5

16 years ago
Created attachment 100903 [details]
Test case

Here is the test case.
(Assignee)

Comment 6

16 years ago
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 7

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

Comment 8

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

The other patch rotted a bit... we don't want to bottom-align
reset/button/submit _inputs_, just <button> elements for now.
For the curious, the fix for bug 162573 is what caused trouble here.
(Reporter)

Comment 11

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

Comment 12

16 years ago
Comment on attachment 100951 [details] [diff] [review]
fix

r=jkeiser
Happy happy joy joy
Attachment #100951 - Flags: review+
(Assignee)

Comment 13

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

Comment 14

16 years ago
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!
(Assignee)

Comment 15

16 years ago
dbaron or rbs, could you sr?  This fixes the input type = button / text
alignment thing.
Nathan, we in fact had pretty much IE's layout before bug 167236 was fixed.  
We're working on improving on that.  ;)

Comment 18

16 years ago
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! :)
(Assignee)

Comment 19

16 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
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...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 101035 [details] [diff] [review]
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_.
Attachment #100951 - Attachment is obsolete: true
In comment 20, paragraph 2 should say "also note that" instead of "also not that".
(Assignee)

Comment 23

16 years ago
bug 167236 backed out.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 24

16 years ago
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)?
(Assignee)

Comment 25

16 years ago
That is bug 167236, and has been the case for time immemorial.
You need to log in before you can comment on or make changes to this bug.