Minimum height of a button is larger on FF3 than FF2

RESOLVED FIXED

Status

()

P3
normal
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: duncan.loveday, Assigned: dbaron)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:RwCo])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070320 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070320 Minefield/3.0a3pre

The height of a button, as set using <INPUT type="button" style="height:<value>px">, seems to have a minimum value of about 20px on FF3 whereas in FF2 there was a much smaller minimum, if any.

Reproducible: Always

Steps to Reproduce:
1. Open the attached test.html
2.
3.
Actual Results:  
A series of buttons of differing heights are displayed. In FF3 all the buttons are at least 20px high. In FF2 they are all different heights.

Expected Results:  
Unless setting small button heights is invalid in the standard, FF3 should behave as FF2.
(Reporter)

Comment 1

12 years ago
Created attachment 259403 [details]
test HTML source
(Reporter)

Comment 2

12 years ago
Adding regression keyword....this has broken an existing layout in my app.
Keywords: regression

Updated

12 years ago
Blocks: 366722
Flags: blocking1.9?
Is this a case that would be improved by separating GetPreferredWidgetSize and GetMinimumWidgetSize, or are we already sort of doing that here (by doing one for HTML and the other for XUL)?
Flags: blocking1.9? → blocking1.9+
Assignee: nobody → dbaron

Updated

11 years ago
Keywords: testcase
Version: unspecified → Trunk
Whiteboard: [dbaron-1.9:RwCo]
Created attachment 288777 [details] [diff] [review]
patch to restore compat to Firefox 2

This makes GetMinimumWidgetSize no-op for HTML buttons on Windows.  I don't think this is a good idea.  The buttons do draw correctly a bit smaller than their supposed minimum, but they become unreasonable pretty quickly.

This does make us do the same thing as Firefox 2 for buttons on Windows.

There are some other possibilities: using TS_MIN instead of TS_TRUE, or trying to select the correct fonts before requesting the size.
Created attachment 288778 [details] [diff] [review]
patch

I think this makes a little more sense -- I'd actually thought we had this code generically for all widgets, but we don't seem to.

That said, it has pretty much the same effect, since it lets the widgets get pretty small.  But I suppose that's ok, and it's what this bug reporter is requesting.  That said, his app will still break on Mac.
Attachment #288777 - Attachment is obsolete: true
Attachment #288778 - Flags: superreview?(roc)
Attachment #288778 - Flags: review?(roc)
Attachment #288778 - Flags: superreview?(roc)
Attachment #288778 - Flags: superreview+
Attachment #288778 - Flags: review?(roc)
Attachment #288778 - Flags: review+
Fix checked in to trunk.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
I filed bug 403934 on splitting GetMinimumWidgetSize.
You need to log in before you can comment on or make changes to this bug.