Closed Bug 1802687 Opened 2 years ago Closed 2 years ago

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)

defect

Tracking

()

RESOLVED FIXED
117 Branch
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

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.

Severity: -- → S4

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.

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.

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?

Flags: needinfo?(jfkthame)

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.

Flags: needinfo?(jfkthame)
Assignee: nobody → jfkthame
Attachment #9320605 - Attachment description: Bug 1802687 - Account for direction:rtl in vertical writing-mode <input type=range> controls. → Bug 1802687 - Account for direction:rtl in vertical writing-mode <input type=range> controls. r=#layout-reviewers
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/811d8bd2f7f9 Account for direction:rtl in vertical writing-mode <input type=range> controls. r=emilio

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.)

Flags: needinfo?(jfkthame)
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2a8a95dd8ab8 Account for direction:rtl in vertical writing-mode <input type=range> controls. r=emilio

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
Flags: needinfo?(jfkthame)

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.

Flags: needinfo?(jfkthame)
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3809d32977a2 Account for direction:rtl in vertical writing-mode <input type=range> controls. r=emilio
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 117 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: