Open
Bug 767374
Opened 13 years ago
Updated 2 years ago
empty <option> has less height than one with text
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
NEW
People
(Reporter: MatsPalmgren_bugz, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
500 bytes,
text/html
|
Details |
STEPS TO REPRODUCE
1. load data:text/html,<select size=1><option><option>Hi</select>
2. dump the frame tree
ACTUAL RESULTS
Block(select)(0)@0x7f6a1ddcac70 [content=0x7f6a1b6bdf30] {120,60,2160,1620} [state=0000000000904010] sc=0x7f6a1a10a3d0(i=0,b=2) pst=:-moz-scrolled-content<
line 0x7f6a1a10b2f0: count=1 state=block,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x108] {0,0,2160,720} <
Block(option)(0)@0x7f6a1a10ae50 next=0x7f6a1a10aee8 [content=0x7f6a1ddc73e0] {0,0,2160,720} [state=0000104000104000] sc=0x7f6a1101dc20(i=0,b=0)<
>
>
line 0x7f6a1a10b330: count=1 state=block,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x8] {0,720,2160,900} <
Block(option)(1)@0x7f6a1a10aee8 [content=0x7f6a1ddc7470] {0,720,2160,900} [state=0000100000104000] sc=0x7f6a1a10aaf0(i=1,b=0)<
line 0x7f6a1a10b2b0: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x100] {180,0,720,900} <
Text(0)"Hi"@0x7f6a1a10b240 [run=0x7f6a1ddcb700][0,2,T] {180,0,720,900} [state=00000040d0604000] [content=0x7f6a1ddcb080] sc=0x7f6a1a10af80 pst=:-moz-non-element
>
>
>
>
The empty option has height 720
EXPECTED RESULTS
The empty option has height 900
Apart from being ugly, another effect of this is that when we limit
the number of visible <option>s in a dropdown to N, the height of it
doesn't fit exactly N <option>s (because we approximate the height
to 'mNumDisplayRows * heightOfARow' currently which will only be
exact if all <option>s have the same height)
Updated•13 years ago
|
Version: unspecified → Trunk
Comment 1•13 years ago
|
||
<option> is rendered as normal nsBlockFrame and the reason why an empty <option> doesn't collapse to nothing is because there's "min-height: 1em" in form.css.
I see two CSS workarounds/solutions for replacing that (test cases attached):
A. option:-moz-only-whitespace::before { content: " "; white-space: pre; }
B. option { min-height: 1.2em; } (not exact, but better)
I would say both are quite hacky and I would prefer a new CSS unit for a line height... or do you want to take a patch that does A?
Given that we already have 'line-height: -moz-block-height', that seems a bit dangerous. Or do you mean a CSS unit for a 'normal' line-height, rather than for what line-height actually is? (I suppose that would seem a little more reasonable if it had slightly better-defined behavior.)
Comment 3•13 years ago
|
||
(In reply to David Baron [:dbaron] from comment #2)
> Given that we already have 'line-height: -moz-block-height', that seems a
> bit dangerous.
Hmm... I don't know what 'line-height: -moz-block-height' does.
> Or do you mean a CSS unit for a 'normal' line-height, rather
> than for what line-height actually is? (I suppose that would seem a little
> more reasonable if it had slightly better-defined behavior.)
Yeah, I think I meant the the length returned by GetNormalLineHeight(), though if you think A. is good enough I am happy to submit a patch too. I am not exactly sure how something like '1ln' is useful in the real world. (Does this count as a use case?).
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•