79927 - submit button with single character value is too small

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P5)

Description

[:glob ✱]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050515

with normal submit buttons, the value of the button (ie what is shown on the
rendered html page) has gaps between the text and the side of the widget.  if
you set the value of a submit button to a single character, the spacing isn't
there, and it looks like the character is truncated.

Reproducible:
  Always

Steps to Reproduce:
  <input type="submit" value="x">

Actual Results:
  the button appears to have it's title truncated.

Expected Results:
  put a gap of a few pixels between the title and the edges of the button.

Comment 1

[John Morrison]

-> HTML Form Controls && confirming.

Comment 2

[rods (gone)]

For what is worth we size the same as Nav 4.x, but smaller than IE

Comment 3

[Niels Aufbau]

This also happens with some two-letter buttons, such as the Iridium (77 Ir)
button at http://www.csrri.iit.edu/periodic-table.html.

Comment 4

[Matthew T (active 1999-2002)]

bz, this is the bug we were talking about. Narrow buttons are too narrow, and wide 
buttons are too wide.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The interesting thing is that while <input type="button|reset|submit"> is sized
wrong, <button> is sized correctly.  Attaching testcase.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase

Comment 7

[Håkan Waara]

Attachment: IE's fugly button sizes

Comment 8

[Håkan Waara]

rods' patch to bug 96630 hardcoded quirks compatibility mode for buttons.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: strict mode testcase

Comment 10

[Boris Zbarsky [:bzbarsky]]

OK.  I see a few problems here...

1)  nsGfxButtonControlFrame::DoNavQuirksReflow has the following comment:

    // Note: The Quirks sizing includes a 2px border in its calculation of
    // "desiredSize"

    This is incorrect.  As far as I can tell, the quirks sizing algorithm does
    nothing of the sort.  So we lose 4px of width here for no reason.  This is
    the root of the problem.  Not subtracting those 4px off makes us size
    correctly (or at least not cut off the text).  Attaching a patch for this.

2)  The left/right padding for these controls in forms.css is 0px!  I'm not sure 
    why <button> is rendering as it does, but it would make sense to me to fix
    <button> to use the same algorithm and make the padding nonzero. IE/Win and
    IE/Mac both seem to do about 5-10 pixels of padding, as do Opera/Mac and
    iCab/Mac (see screenshots in bug 108424 and the IE screenshot in this bug).

This should be the topic of a separate bug, in my opinion.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: proposed patch

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, and as regards the original testcase... The "bad" cases should be fixed by
this patch and some default padding. The "too much" case is there for
compatibility with IE/Win, unfotunately. And it's not likely to go away...

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: testcase using several different types of controls

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: patch that fixes <input type="text">, <select>, <input type="submit> to have same height (and fixes width)

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[rods (gone)]

Attachment: patch

I can live with this patch, but anything else will change the button sizes too
much.

Comment 18

[John Keiser (jkeiser)]

rods: I don't really like the special-casing there.  Why does it make sense to
subtract out the 2-pixel border when there is one character but not when there
are others?  Does IE do that?  Does it *matter* whether IE does that when it
comes to 2 pixels in a form control, which most people render differently anyway?

bz: I don't think we should be changing the heights of text/select/submit to be
the same in this bug, though I *do* think that should be a new bug.  While I
personally think it makes a great deal of sense to make them the same size by
default, I am not sure of the ramifications to compatibility/page sizing/etc. are.

I vote for the obsoleted patch :)

Comment 19

[basic]

rods: can the sizing be moved to quirks.css ?

Comment 20

[Håkan Waara]

Why would we move it to the Quirks stylesheet? As far as I can tell, this is not
a quirks vs. standard mode compatibility thing. All other browsers size their
buttons like bz's patch - I think we should go with that patch.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Just to clarify.  My patch does not make us size like other browsers.  It just
makes us not cut off the text.  So does rods' patch.  Other browsers actually
put padding around the text too...  we will not with my patch, or rods'.

The "size as other browsers" issue is still being hashed out (unlike the
"cutting off text issue", which everyone agrees is bad).

Comment 22

[John Keiser (jkeiser)]

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

Comment 23

[Aaron Kaluszka]

Is there a reason that this hasn't gone in?

Comment 24

[Boris Zbarsky [:bzbarsky]]

My patch didn't go in because rods (module owner) was opposed to it.  Rod's
patch did not go in because it does not really fix the bug in my testing (eg
using two lowercase 'L's with variable-width font).

Comment 25

[Boris Zbarsky [:bzbarsky]]

fixed by bug 167236

Comment 26

[Aaron Kaluszka]

v 2002111308-trunk/WinXP