1750135 - New wpt failures in /css/CSS2/ [lists/list-style-position-018.xht, syntax/at-charset-012.xht, text/text-transform-bicameral-003.xht, and 1 others]

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Syncing wpt PR 32125 found new untriaged test failures in CI

Tests Affected

Firefox-only failures

/css/CSS2/lists/list-style-position-018.xht: FAIL
/css/CSS2/syntax/at-charset-012.xht: FAIL [Gecko-linux1804-64-qr-debug, Gecko-linux1804-64-qr-opt, Gecko-linux1804-64-tsan-qr-opt, GitHub], PASS [Gecko-android-em-7.0-x86_64-lite-qr-debug-geckoview, Gecko-android-em-7.0-x86_64-lite-qr-opt-geckoview, Gecko-android-em-7.0-x86_64-qr-debug-geckoview, Gecko-android-em-7.0-x86_64-qr-opt-geckoview]
/css/CSS2/text/text-transform-bicameral-003.xht: FAIL
/css/CSS2/text/text-transform-bicameral-004.xht: FAIL

CI Results

Gecko CI (Treeherder)
GitHub PR Head

Notes

These updates will be on mozilla-central once bug 1746563 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.

Comment 1

[Daniel Holbert [:dholbert]]

Going through the tests from comment 0 here:

list-style-position-018.xht
wpt.fyi: https://wpt.fyi/results/css/CSS2/lists/list-style-position-018.xht
live test: https://wpt.live/css/CSS2/lists/list-style-position-018.xht
If you use devtools to change the background-color from black to lime, then you can see what's happening -- we're positioning the bullet marker according to the text-align property.

(As a quick hack, I checked if li::marker { text-align:left} made a difference, but that doesn't seem to change the rendering at all.)

This seems like maybe a real bug, or maybe a surprising-but-correct outcome from our "implement li in terms of CSS lists" work that mats did in the past year or so; I don't know enough about the details here to be sure without further investigation.

at-charset-012.xht
wpt.fyi: https://wpt.fyi/results/css/CSS2/syntax/at-charset-012.xht
live test: http://wpt.live/css/CSS2/syntax/at-charset-012.xht

Looking at the WPT analyzer screenshot, it looks like we're just rendering the testcase and reference case with a different font. I think the testcase is rendering with the default Japanese-language (lang="ja") font, due to <?xml version="1.0" encoding="shift-JIS"?>, which seems to be a Japanese encoding. I can reproduce that font behavior locally, e.g. these two examples use different fonts:

data:text/html,<?xml version="1.0" encoding="shift-JIS"?>Hello
data:text/html,Hello

So I think this is an accidentally-bogus test-expectation. Perhaps this testcase wants its own reference case (right now it uses a shared reference case from another test), and the reference case would want lang="ja" on the root element?

(Note, this test has apparently been untouched since 2017; I'm not sure why it got caught up as something noteworthy for this bug at the moment.)

text-transform-bicameral-003.xht
wpt.fyi: https://wpt.fyi/results/css/CSS2/text/text-transform-bicameral-003.xht
live test: https://wpt.live/css/CSS2/text/text-transform-bicameral-003.xht

Looks like this is just a fuzzy-mismatch. The wpt.fyi comparison shows maxDifference: 24 totalPixels: 3, with the mismatching pixels being on the fringe of the bottom-left corner of the second fancy "F", ƒ.

text-transform-bicameral-004.xht
wpt.fyi: https://wpt.fyi/results/css/CSS2/text/text-transform-bicameral-004.xht
live test: https://wpt.live/css/CSS2/text/text-transform-bicameral-004.xht

This one's a fuzzy-mismatch, too, except that here it's for the first fancy-c character, "Ƈ"
maxDifference: 176
totalPixels: 3

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)

list-style-position-018.xht

Reduced testcase for this one:

data:text/html,<ul style="text-align:right; width: 400px"><li style="list-style-position:outside">Hi

Firefox renders the bullet on the right side (next to the text); Chrome renders it on the left side.

Firefox's behavior goes back quite a ways (e.g. Firefox 32 was the oldest version I tested and it matches Nightly) so this isn't a recently-introduced behavior.

Comment 3

[Gérard Talbot]

Regarding list-style-position-018.xht ,

Firefox 112.0a1 buildID=20230312211644 passes this test. Firefox 113's test success is also noticed in

https://wpt.fyi/results/css/CSS2/lists/list-style-position-018.xht