994839 - Improve the internal layout of <select> child frames

Status: NEW

(Core :: Layout: Form Controls, enhancement)

Description

[Mats Palmgren (inactive)]

Follow-up from bug 992447 comment 4:

Currently, the child frame for the dropdown button is placed outside
the nsComboboxControlFrame content area, so technically it causes
overflow, which is problematic for example when using 'text-overflow'
or 'overflow-clip-box'.

I wonder if the right fix is to have a zero-sized padding area for the
nsComboboxControlFrame itself, and have the padding applied to its
anonymous inner frame instead, like so:

########################################
#pppppppppppppppppppppp||||||||||||||||#
#pppppppppppppppppppppp||||||||||||||||#
#pppp            pppppp||||||||||||||||#
#pppp            pppppp||||||||||||||||#
#pppp            pppppp||||||||||||||||#
#pppp            pppppp||||||||||||||||#
#pppppppppppppppppppppp||||||||||||||||#
#pppppppppppppppppppppp||||||||||||||||#
########################################

Where p=padding on the inner anon block, #=outer border, |=button,
and the content area for outermost frame is everything inside #
(i.e. zero padding).  That should fix 'overflow-clip-box' properly
if we put 'overflow-clip-box:inherit' (in the UA sheet) on the inner
frame and 'overflow-clip-box:content-box' on the outer, which would
give you the blank area above as the clip area by default.  If the
author specifies 'padding-box', the inner content can overflow into
the 'p' area but not beyond it.

(This design should also work for <select> lists where '|' is
instead the scrollbar.)

Comment 1

[Mats Palmgren (inactive)]

(We might also want to reconsider if nsComboboxControlFrame really
should be a nsBlockFrame subclass, but that seems like a separate
issue.)

Comment 2

[Alex Henrie]

I've been looking into this, and I have a question: How do we make nsComboboxControlFrame ignore its padding? Moving the display frame and the button around looks easy enough, but nsComboboxControlFrame will still clip the button because it still thinks it has padding.

Comment 3

[Mats Palmgren (inactive)]

Attachment: wip1

Perhaps we can override it with a UsedPaddingProperty?
(see nsIFrame::GetUsedPadding())

It's a bit of a hack though...

Comment 4

[Mats Palmgren (inactive)]

It might be simpler to find the few places in layout where
'overflow-clip-box' is implemented and make an exception for
nsComboboxControlFrame? (make it always take the padding-box
branch).

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #1, px padding.

Comment 6

[Mats Palmgren (inactive)]

Attachment: Testcase #2, % padding.

Note that this test shows an existing bug - the button doesn't fill the
height when resizing the window (narrow).  Do we have a bug open on this?

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase #3, px padding and -moz-appearance:none

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase #4, % padding and -moz-appearance:none

Comment 9

[Mats Palmgren (inactive)]

Comment on attachment 8643208 [details] [diff] [review]
wip1

To my surprise, this actually seems to work quite well, fwiw.
There was only one reftest failure:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1a3177eed1f
and that's a <select> list - which makes sense since I changed
the generic 'select' rule but only update the combobox code.

So I guess we should also investigate how 'overflow-clip-box' works
for the list (size > 1) case.