1877811 - New wpt failures in /css/css-display/accessibility/display-contents-role-and-label.html

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

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

Syncing wpt PR 43740 found new untriaged test failures in CI

Tests Affected

Firefox-only failures

• /css/css-display/accessibility/display-contents-role-and-label.html [wpt.fyi]
  • div with role grid with display: contents has grid role: FAIL
  • Label: g element with display: contents, as child of svg, is labelled via title element: FAIL

New Tests That Don't Pass

• /css/css-display/accessibility/display-contents-role-and-label.html [wpt.fyi]
  • Label: td as child of tr with display: contents, within table with display: flex, has cell role: FAIL (Chrome: PASS, Safari: FAIL)
  • Label: td as child of tr with display: contents, within table with role=table with display: flex, has cell role: FAIL (Chrome: PASS, Safari: FAIL)
  • Label: td within tr in table with role table, all with display: contents, has cell role: FAIL (Chrome: PASS, Safari: FAIL)

CI Results

Gecko CI (Treeherder)
GitHub PR Head

Notes

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

Several of our failures here are of-the-form

PROMISE_REJECT(object "TypeError: can't access property "replace", computedLabel is null")

The failing "replace" operation there is probably from this code in one of the JS libraries that this test uses:
https://searchfox.org/mozilla-central/rev/5c4a45eb17423373ecb71aea9819d41a6231613e/testing/web-platform/tests/wai-aria/scripts/aria-utils.js#130,140,152

verifyLabelsBySelector: function(selector) {
...
      let computedLabel = await test_driver.get_computed_label(el);
...
      computedLabel = computedLabel.replace(asciiWhitespace, '\u0020').replace(/^\u0020|\u0020$/g, '');

It looks like it's unexpected that the computedLabel would ever be null here, but clearly it is null for us right now. Probably it'd be nice for this utility script to assert that computedLabel is not-null before trying to do replace on it, so that the test-failure can be clearer.

Comment 2

[Daniel Holbert [:dholbert]]

I'm addressing comment 1 in https://github.com/web-platform-tests/wpt/pull/44361 (just changing those test-failures from one form to another).

Comment 3

[Nathan LaPré]

Attachment: Bug 1877811: Maybe create SVG accessible in display:contents contexts, r?Jamie

Since SVG elements aren't in a markup map, Gecko doesn't check for them when
searching markup maps while determining whether to create an accessible in
display:contents contexts. This revision addresses the problem by factoring out
the SVG creation code and using it in two places - newly in the dislay:contents
code. This revision also removes expected failures from relevant web platform
tests.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ceae8bb81d3d
Maybe create SVG accessible in display:contents contexts, r=Jamie

Comment 5

[Nathan LaPré]

Marking this leave-open; there are a few different things to address in this test file.

Comment 6

[tszentpeteri]

https://hg.mozilla.org/mozilla-central/rev/ceae8bb81d3d