1492338 - Firefox isn't internally consistent about sizing of empty vs. near-empty <select> elements

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect, P4)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit https://jsfiddle.net/boae3d72/
 2. Inspect the measurements (reported as width, height) displayed in the results area.

EXPECTED RESULTS:
 - The first and second ("selEmpty" and "selOptionEmpty") measurements should probably be equal.
  (These are an empty <select>, vs. a <select> with a single empty <option>.)

 - The third "selOptionNbsp" should perhaps be a bit wider, or perhaps the same. (This is for a <select> with a single <option> which just contains a &nbsp; character.)


ACTUAL RESULTS:
 - In Firefox Nightly on Linux, the first and third (selEmpty and selOptionNbsp) are the same, whereas the second is near-identical -- it's 1px shorter. (??)


Other browsers, for comparison:
- Chrome and Edge each gives EXPECTED RESULTS. Its first two elements are the same size, and the third is a bit wider.
- In Safari, all three elements are the same size, which is kind of a version of EXPECTED RESULTS.

This seems to be causing problems in bug 1476127 -- in that bug, it seems that we have trouble "pretending" that a nonempty select is empty, for measurement purposes, because an actually-empty select seems to have some special content size (which I think might be the same special size that's causing trouble here, but I'm not 100% sure).

Comment 1

[Morgan Reschenberg [:morgan]]

FWIW, MacOS has some (different) weird results on Nightly (64.0a1 (2018-09-19) (64-bit)). I get:

selEmpty: 27.5, 18.5
selOptionEmpty: 35, 17.5
selOptionNbsp: 38.149993896484375, 18.5

I also get this on Safari mobile (iOS12):

selEmpty: 32, 20
selOptionEmpty: 32, 20
selOptionNbsp: 36, 20

Comment 2

[Daniel Holbert [:dholbert]]

Interesting! Thanks for those results.

* Height-wise, your MacOS results are consistent with my Linux measurements. (selOptionEmpty is 1px shorter than the others, for some reason.)
* Your Safari Mobile results are consistent with what I observed in Chrome / Edge. (First two the same, third a bit wider.)

Comment 3

[Daniel Holbert [:dholbert]]

For completeness: my Firefox Nightly on Linux measurements (on 64.0a1 (2018-09-18) (64-bit)) are as follows:
selEmpty: 44, 31
selOptionEmpty: 44, 30
selOptionNbsp: 44, 31

Comment 4

[Mats Palmgren (inactive)]

Seems to work for me in Nightly on Linux:
selEmpty: 44, 31
selOptionEmpty: 44, 31
selOptionNbsp: 44, 31

Nightly on OSX:
selEmpty: 34.149993896484375, 19
selOptionEmpty: 35, 19
selOptionNbsp: 38.15000915527344, 19

Maybe bug 1499578 fixed the block-size?

Bug 1499230 / bug 1499184 might help with the inline size.
(fwiw, selOptionNbsp is slightly wider in Chrome/Edge too, but not Safari)

I think block-size is more important than inline-size though and that
part seems to be fixed now, so lowering the importance to minor.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #4)
> Seems to work for me in Nightly on Linux:

Same.

> Maybe bug 1499578 fixed the block-size?

Yup. Nightly fix range includes that bug's patch:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b2fa4b07f6f7e489047808bd0238301ea943b4b3&tochange=2872e7a3606d6108874930a1eb4062c74bad0e9e

> I think block-size is more important than inline-size though and that
> part seems to be fixed now, so lowering the importance to minor.

IIRC both are important in order for us to be able to implement "contain:size" gracefully (bug 1476127).  But setting that part aside, agreed RE lowered importance as a result of block size being fixed.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a bugzilla-hosted version of comment 0's jsfiddle testcase, BTW.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Morgan Reschenberg [:morgan] from comment #1)

FWIW, MacOS has some (different) weird results on Nightly (64.0a1 (2018-09-19) (64-bit)). I get:

selEmpty: 27.5, 18.5
selOptionEmpty: 35, 17.5
selOptionNbsp: 38.149993896484375, 18.5

Maybe this has gotten better? Right now I'm getting nearly-consistent measurements on Mac ("Mojave", on a remote machine viewed using BrowserStack, using Firefox Beta 67 on that Mac machine).
selEmpty: 38.149993896484375, 19
selOptionEmpty: 38.15000915527344, 19
selOptionNbsp: 38.149993896484375, 19

The difference in the second measurement there as compared to the first/third is ~ 0.000015px, which is much less than an app unit in size (1/60th pixel i.e. 0.016px), so I suspect it's just a rounding error or some other weird unimportant artifact.

And I do get consistent results on Linux and BrowserStack-hosted Windows10:
Linux, Firefox Nightly 69: 44, 25 (for all 3 measurement rows)
Windows, Firefox Beta 67: 31, 20 (for all 3 measurement rows)

Comment 8

[Mats Palmgren (inactive)]

Linux, Firefox Nightly 69: 44, 29 (for all 3 measurement rows)
OSX Mojave (10.14.4), Firefox Nightly 69:
selEmpty: 38.100006103515625, 18.5
selOptionEmpty: 38.09999084472656, 18.5
selOptionNbsp: 38.100006103515625, 18.5

Comment 9

[Daniel Holbert [:dholbert]]

I just confirmed that on my Mac machine, the remaining (negligible) difference between the select boxes is simply due to rounding error and conversion issues.

All three select elements have width=2286 app units, but their x positions var and aren't necessarily pixel-aligned (in layout). (In particular, they have x=480, 3006, and 5532.) And the API in the testcase here, getBoundingClientRect, produces its resulting rect in an "x, y, XMost(), YMost()" representation (where XMost() = x + width):
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/dom/base/Element.cpp#1036
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/dom/base/DOMRect.cpp#83-84

So: even for equally-sized objects, they may end up with a subtly different getBoundingClientRect rect-widths if they're positioned at spots that trigger rounding behavior.

So: the remaining differences here are negligible and well-understood, and are in fact not a difference at all at the nscoord level. And the significant "real" differences from comment 0 and comment 1 have gone away. So, this is WORKSFORME.