Closed
Bug 90884
Opened 23 years ago
Closed 22 years ago
submit button does not properly display text when line-height attribute is set to > 100% in parent container
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: daisuke, Assigned: rods)
References
Details
(Keywords: testcase)
Attachments
(3 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628
BuildID: 20010628
<div style="line-height:1em">
<form>
<input type="submit" value="BLAH"> TEST with 1em
</form>
</div>
<div style="line-height:1.5em">
<form>
<input type="submit" value="BLAH"> TEST with 1.5em
</form>
</div>
<div style="line-height:150%">
<form>
<input type="submit" value="BLAH"> TEST width 150%
</form>
</div>
the <input type="submit"> form element displays incorrectly when the
parent container has a line-height attribute set.
The last two examples in above HTML makes the text in the "value" field of
the <input> tag to be displayed slightly below the visible range of the button.
Also, the button seems to be placed a little bit below the text, compared to the
first example, which has line-height of 1em ( btw, same results if no
line-height is set)
Reproducible: Always
Steps to Reproduce:
1. Just display the HTML in the description
2.
3.
Comment 1•23 years ago
|
||
WFM Linux today's tip. Testcase coming up.
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
WFM on win98, build ID 2001090408
However, the text in the two lower buttons is slightly lower in the button
istelst then in the top one (but the text does not get cut off).
Comment 4•23 years ago
|
||
I also see the text in the buttons is not centered in the last two buttons.
However it is not cut off and still readable. Maybe this should still be a bug
though? Using mozilla0.9.3 on win2k.
Comment 5•23 years ago
|
||
Comment 6•23 years ago
|
||
Looks like the line-height is being respected, the text is being centered in the
height, but the button height isn't changed(I don't know if it should be) I've
attached a file which shows this with lots of buttons side-to-side (attachment
49900)
confirming original testcase with build 2001100303 win32 on w2k. The text in the
last button is not visible. Question: should the height of the button change
according the line height since the height of the button is not set?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 8•23 years ago
|
||
Still seeing this in 0.9.9
My case was in a <ul> with line-height set to 3. With a submit as an <li>
element, the text drops mostly off the bottom of the button.
Why is this futured? This clearly should be fixed on some timescale.
OS: Windows 2000 → All
Hardware: PC → All
Comment 9•22 years ago
|
||
Still seeing this in 1.0 (WinXP)... this bug doesn't just affect submit buttons,
it seems to affect any input field that can contain text (e.g. a text box, i.e.
<input type=text>). Another testcase coming up...
Comment 10•22 years ago
|
||
Comment 11•22 years ago
|
||
I almost submitted a new bug for this, but hey, bugzilla search works really well.
I can verify this broken behavior on OS X (10.2) in Mozilla 1.1 and Chimera 0.5
(nightly build from Sept 12, '02.
Here's how I found it: some page designers bump the line-height attribute to >
1.0 in order to make better use of whitespace. This is very important on pages
that have a lot of text -- makes the page _much_ more readable.
I consistently see the button text moved down to the bottom of the button, as
described in this bug. I know this bug is already assigned, but I just wanted to
provide another point of reference or "vote" to please fix this one.
thanks,
Brian
Comment 12•22 years ago
|
||
Fixed by checkin for bug 82265.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 13•22 years ago
|
||
verified on winxp and linux with testcase attachment 42348 [details]
Status: RESOLVED → VERIFIED
Keywords: testcase
You need to log in
before you can comment on or make changes to this bug.
Description
•