17474 - html and input buttons do not obey CSS width,height

Status: VERIFIED FIXED

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

Description

[rods (gone)]

The HTML button minimum size is always the content, there is no way to make the
button size smaller than the content.

This is blocking me because I cannot get the comboboxes to size correctly
without this being fixed.

Comment 1

[rods (gone)]

Attachment: demonstrates the problem for both GFX buttons and HTML buttons

Comment 2

[rods (gone)]

Part of the problem is right here:
  // if computed use the computed values.
  if (aReflowState.mComputedWidth != NS_INTRINSICSIZE && (aDesiredSize.width <
aReflowState.mComputedWidth))
    aDesiredSize.width = aReflowState.mComputedWidth;
  else
    aDesiredSize.width  += focusPadding.left + focusPadding.right;

  if (aReflowState.mComputedHeight != NS_INTRINSICSIZE && (aDesiredSize.height <
aReflowState.mComputedHeight))
    aDesiredSize.height = aReflowState.mComputedHeight;
  else
    aDesiredSize.height += focusPadding.top + focusPadding.bottom;

It should be:
  // if computed use the computed values.
  if (aReflowState.mComputedWidth != NS_INTRINSICSIZE)
    aDesiredSize.width = aReflowState.mComputedWidth;
  else
    aDesiredSize.width  += focusPadding.left + focusPadding.right;

  if (aReflowState.mComputedHeight != NS_INTRINSICSIZE)
    aDesiredSize.height = aReflowState.mComputedHeight;
  else
    aDesiredSize.height += focusPadding.top + focusPadding.bottom;

But doing this then causes a clipping problem when the text is drawn.

Comment 3

[rods (gone)]

Attachment: New attachment shows standard button size is wrong

Comment 4

[rods (gone)]

This could be a separate bug, but the default size for a button is too tall and
not wide enough for a given piece of text in NavQuirks mode. The new attachment
shows this.

Comment 5

[Eric Vaughan]

I'll take a look at this.

Comment 6

[rods (gone)]

I have completed the code for making the GfxButton size correctly in
NavQuirks, in Standard mode it will use the nsHTMLButtonControlFrame's
reflow. The nsHTMLButtonControlFrame::Reflow still needs to obey the sizes that
are passed in so not much has chnaged with this bug.

Comment 7

[Sean Richardson]

Attachment: testcase - wrong CSS sizing of input text if other attributes

Comment 8

[Sean Richardson]

It looks like this affect more types of <input>s than just "button".
Testcase added ("testcase - wrong CSS sizing of input text if other attributes")
showing <input type="text"> too small if sized in ems, and <input size="1">
too large whether sized in ems or in pixels. Guessing that this interaction
problem affects all <input> elements sized by CSS - but if this is a "button"
bug more than a CSS size bug I'll create a new report for <input type="text">
sizing.

Tested with 1999-11-06-08-M11 on Windows NT.

Comment 9

[Peter Trudelle]

Rod, is this really blocking you from doing useful work?  If so, please put on
dogfood radar.  If not, it shouldn't be marked blocker severity. Removing
extraneous 'blocker' from whiteboard. Eric, this needs a target milestone.

Comment 10

[Peter Trudelle]

targetting m13, p2

Comment 11

[gerardok]

QA Contact update.

Comment 12

[Eric Vaughan]

This if fixed however with nav quirks turned on the text is not vertically
centered correctly. So I'm closing out this but and opening a new one for that
bug.

Comment 13

[Sean Richardson]

The sizing of the buttons in both of the first two testcases is now matching
what is specified in the STYLE attributes in the code, and text that does
not fit inside the buttons is clipped, rather than enlarging the button.

The issues with sizing of input type=text noted in Comments From [e-mail]
11/07/99 13:25 are no longer present, either.

Comment 14

[ckritzer (gone)]

Marking VERIFIED on:
- Win98 2000-01-24-00 bugzilla build
- Linux6 2000-01-24-01 commercial build
- MacOS86 2000-01-24-02 commercial build