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.
Adding regression keyword....this has broken an existing layout in my app.
The regression range I found is: 20070117 works 20070118 broke http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-01-17+04%3A00%3A00&maxdate=2007-01-18+04%3A00%3A00&cvsroot=%2Fcvsroot I suspect Bug 366722.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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+
Priority: -- → P3
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.
Fix checked in to trunk.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
I filed bug 403934 on splitting GetMinimumWidgetSize.
You need to log in before you can comment on or make changes to this bug.