Bugzilla

I'm going to be posting a "mostly-there" fix here, and I'm going to spin off a followup for the remaining work.

With my patch, we'll size all `<select style="contain:size">` elements independently from their content, but we won't **quite** size them the same as we do for empty `<select>` elements (which is really what we should be doing) -- they'll be a bit skinnier.

This is because empty `<select></select>` elements **aren't actually empty**.  Their frametree looks like this (cleaned up a bit for readability):
```
             ComboboxControl(select)(1)<
                line  <
                  ComboboxDisplay(select)(1)[cs=7fe232ee93d8:-moz-display-comboboxcontrol-frame]<
                    line <
                      Text(-1)"\u00a0"[cs=7fe232ee9888:-moz-text] [run=0][0,1,T] 
                    >
```

Note the `\u00a0` character there -- that is an [`&nbsp;` nonbreaking-space character](http://www.fileformat.info/info/unicode/char/00a0/index.htm).

So, "empty" `<select>` elements get a little bit of width from that character, which means our usual contain:size behavior (use a zero size and/or emulate the we-have-no-descendant-frames codepath) doesn't quite do the right thing here.  I think that's a reasonable compromise behavior for now, though, because:
(a) with native widget styling (on linux at least), we actually do end up matching the size of an empty select element, probably because the widget has a system-imposed minimum size or something.
(b) the main goal is to size independently of your contents, and we match that goal.  (This is what enables e.g. reflow root optimizations.)
(c) the difference is pretty subtle.
(d) there aren't really any real-world use-cases for a size-contained auto-sized <select> element that I can think of (not any that would benefit from having exactly one `&nbsp;` worth of width, at least), so I doubt anyone will care about this not-quite-complete implementation in practice.

I'm going to be posting a "mostly-there" fix here, and I'm going to spin off a followup for the remaining work.

With my patch, we'll size all `<select style="contain:size">` elements independently from their content, but we won't **quite** size them the same as we do for empty `<select>` elements (which is really what we should be doing) -- they'll be a bit skinnier.

This is because empty `<select></select>` elements **aren't actually empty**.  Their frametree looks like this (cleaned up a bit for readability):
```
             ComboboxControl(select)(1)<
                line  <
                  ComboboxDisplay(select)(1)[cs=7fe232ee93d8:-moz-display-comboboxcontrol-frame]<
                    line <
                      Text(-1)"\u00a0"[cs=7fe232ee9888:-moz-text] [run=0][0,1,T] 
                    >
```

Note the `\u00a0` character there -- that is an [`&nbsp;` nonbreaking-space character](http://www.fileformat.info/info/unicode/char/00a0/index.htm).

So, "empty" `<select>` elements get a little bit of width from that automatically-inserted character, which means our usual contain:size behavior (use a zero size and/or emulate the we-have-no-descendant-frames codepath) doesn't quite do the right thing here.  I think that's a reasonable compromise behavior for now, though, because:
(a) with native widget styling (on linux at least), we actually do end up matching the size of an empty select element, probably because the widget has a system-imposed minimum size or something.
(b) the main goal is to size independently of your contents, and we match that goal.  (This is what enables e.g. reflow root optimizations.)
(c) the difference is pretty subtle.
(d) there aren't really any real-world use-cases for a size-contained auto-sized <select> element that I can think of (not any that would benefit from having exactly one `&nbsp;` worth of width, at least), so I doubt anyone will care about this not-quite-complete implementation in practice.