New wpt failures in /css/css-writing-modes/forms/ [range-input-appearance-native-vertical-rtl.optional.html, range-input-appearance-none-vertical-rtl.optional.html]
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox117 | --- | fixed |
People
(Reporter: wpt-sync, Assigned: jfkthame)
References
Details
(Whiteboard: [wpt])
Attachments
(1 file)
Syncing wpt PR 37131 found new untriaged test failures in CI
Tests Affected
Firefox-only failures
- /css/css-writing-modes/forms/range-input-appearance-native-vertical-rtl.optional.html [wpt.fyi]:
FAIL
- /css/css-writing-modes/forms/range-input-appearance-none-vertical-rtl.optional.html [wpt.fyi]:
FAIL
CI Results
Gecko CI (Treeherder)
GitHub PR Head
Notes
These updates will be on mozilla-central once bug 1802674 lands.
Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.
This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/
If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Looking at this, I'm wondering what the expectations should be for <input type=range> controls (and similarly for <meter> and <progress> elements, I guess) in vertical writing modes. Do they progress downwards in vertical Japanese/Chinese content? That's not what we currently do; they progress upwards by default, even though the inline direction of the text is downwards.
Assuming this is correct (is it?), then it's not clear to me that direction:rtl should cause a reversal. See https://github.com/web-platform-tests/interop/issues/294#issuecomment-1450621085, where I'm hoping for some feedback/clarification.
Assignee | ||
Comment 2•2 years ago
|
||
Assignee | ||
Comment 3•2 years ago
|
||
Here's a patch that causes these tests to start passing; however, not flagging for review at the moment as I'm unsure (per comment 1 and the wpt issue) what the correct expectations should be.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
Now that https://github.com/web-platform-tests/interop/issues/294#issuecomment-1450621085 is fixed, anything else blocks us from moving the patch forward to review?
Assignee | ||
Comment 5•2 years ago
|
||
I guess we can go ahead and try this; afaict the patch here will make these tests pass. There's still an open discussion issue at https://github.com/whatwg/html/issues/8413 regarding what the behavior really ought to be in these cases. It's basically a cosmetic question, though, and we can always update later if some more definitive conclusion emerges.
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Backed out changeset 811d8bd2f7f9 (Bug 1802687) for causing failures in range-vlr.html CLOSED TREE
Log: https://treeherder.mozilla.org/logviewer?job_id=421901972&repo=autoland&lineNumber=11925
Backout: https://hg.mozilla.org/integration/autoland/rev/2c24a29355e9365b4041da3ff96eb9a45c229e4f
Assignee | ||
Comment 8•2 years ago
|
||
Ah, aside from the WPTs affected here, we also have some mozilla reftests that assumed the previous behavior -- they'll need to be updated to set RTL direction on the vertical control in order to grow from bottom to top, as expected by the reference.
(This relates to the still-open questions in https://github.com/whatwg/html/issues/8413, but for now at least we'll be following Tim's proposed behavior from https://github.com/whatwg/html/issues/8413#issuecomment-1332508940.)
Comment 10•2 years ago
|
||
Backed out for causing wpt failures on range-snap-to-tick-marks-03.html.
[task 2023-07-08T04:08:00.561Z] 04:08:00 INFO - TEST-START | /_mozilla/html/rendering/non-replaced-elements/form-controls/range-snap-to-tick-marks-03.html
[task 2023-07-08T04:08:00.566Z] 04:08:00 INFO - Closing window 76caab81-375d-46db-bf61-3970c91820f6
[task 2023-07-08T04:08:00.923Z] 04:08:00 INFO - PID 23516 | 1688789280923 Marionette INFO Marionette enabled
[task 2023-07-08T04:08:01.193Z] 04:08:01 INFO - PID 23516 | 1688789281192 Marionette INFO Listening on port 39970
[task 2023-07-08T04:08:01.270Z] 04:08:01 INFO - {'actions': [{'type': 'none', 'actions': [{'type': 'pause', 'duration': 16}, {'type': 'pause', 'duration': 16}, {'type': 'pause', 'duration': 16}], 'id': '0'}, {'type': 'pointer', 'actions': [{'type': 'pointerMove', 'x': 10, 'y': 153, 'origin': 'viewport'}, {'type': 'pointerDown', 'button': 0}, {'type': 'pointerUp', 'button': 0}], 'parameters': {'pointerType': 'mouse'}, 'id': '1'}]}
[task 2023-07-08T04:08:01.394Z] 04:08:01 INFO -
[task 2023-07-08T04:08:01.395Z] 04:08:01 INFO - TEST-UNEXPECTED-FAIL | /_mozilla/html/rendering/non-replaced-elements/form-controls/range-snap-to-tick-marks-03.html | Snap to a vertical slider's tick marks by clicking near them - assert_equals: expected "-3" but got "33"
[task 2023-07-08T04:08:01.395Z] 04:08:01 INFO - snapToVerticalTickMarks@http://web-platform.test:8000/_mozilla/html/rendering/non-replaced-elements/form-controls/range-snap-to-tick-marks-03.html:42:20
[task 2023-07-08T04:08:01.396Z] 04:08:01 INFO - TEST-OK | /_mozilla/html/rendering/non-replaced-elements/form-controls/range-snap-to-tick-marks-03.html | took 837ms
Assignee | ||
Comment 11•2 years ago
|
||
Ugh, one more test that assumed the upward progression for a vertical-writingmode <range>. We can fix that similarly by adding direction:rtl to restore the expected behavior; and let's also add a version of the test with downward progression, for completeness.
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
bugherder |
Description
•