Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox113 | --- | fixed |
People
(Reporter: dholbert, Assigned: dholbert)
References
Details
Attachments
(1 file)
We've got some WPT failures here:
https://wpt.fyi/results/css/css-writing-modes/forms/text-input-block-size.optional.html
All the failures are of the form:
assert_equals: width of vertical input matches height of horizontal input
expected 23 but got 22
We've got Linux-specific failure annotations in the corresponding .ini file which I think are these same issues, I think.
If I view the test directly (at http://wpt.live/css/css-writing-modes/forms/text-input-block-size.optional.html ) or run it manually (./mach wpt ./testing/web-platform/tests/css/css-writing-modes/forms/text-input-block-size.optional.html), the test fully passes (which in this case means unexpected-pass, given that I'm on Linux and given the aforementioned annotations).
But I can reproduce the failures if I run in headless mode, like so:
./mach wpt --headless ./testing/web-platform/tests/css/css-writing-modes/forms/text-input-block-size.optional.html
|
Assignee | |
Comment 1•2 years ago
•
|
||
Tentative guess: this might actually be expected due to baseline-alignment being different between vertical vs. horizontal writing-modes. The alignment on the central baseline might end up having the text be aligned at a 0.5px-different position in a vertical WM, which then ends up making the line 1px taller. Similar to what was going on in bug 1808997, where we also ended up with an explainable 1px difference in a vertical writing mode.
|
|
Assignee | |
Comment 2•2 years ago
•
|
||
Notably, the testcase doesn't explicitly set any particular font-size here right now, so we've just got the UA default font-size for input, which in my case happens to be 13.3333px. It's not surprising that we might get a 1px discrepancy in the line-height when laying out an odd, fractional-sized line of text using its ideographic baseline vs. its central baseline (if we do pixel snapping or similar rounding at the edges of the line).
So: I think the testcase is curently unsound, and we should fix it to use Ahem font with 30px font-size, as in bug 1808997, for a more predictable & reliably-whole-pixel-valued baseline-position, and hence a predictably consistent widget size regardless of writing-mode.
|
|
Assignee | |
Comment 3•2 years ago
|
||
[CC'ing ntim, since he was the test author here.]
|
|
Assignee | |
Comment 4•2 years ago
|
||
Before this patch, Firefox fails this test's expectations on Linux, with a 1px
sizing discrepancy between the input element in a vertical writing-mode
vs. horizontal.
That discrepancy is almost certainly due to the difference in baselines
(central vs. ideographic) in vertical vs. horizontal writing-modes, and the
fact that pixel-snapping that baseline might produce a +/-1px difference in
block-position and block-size of the line, inside the form-field.
This patch changes the test to use the Ahem font with a font-size of 30px,
which should have a whole-pixel-valued central as well as ideographic baseline;
so no pixel-snapping should be necessary, and the input element's size should
be be consistent, just as the test expects it to be.
This patch also makes one non-functional change, to explicitly declare the
charset as UTF-8, per WPT best-practices from
http://web-platform-tests.org/writing-tests/general-guidelines.html#character-encoding
|
||
Updated•2 years ago
|
|
||
Comment 7•2 years ago
|
||
| bugherder | ||
Description
•