Open Bug 1976355 Opened 1 year ago Updated 1 year ago

New wpt failures in /css/ [css-align/blocks/align-content-table-cell.html, css-inline/text-box-trim/border-padding-001.html, css-inline/text-box-trim/border-padding-002.html, and 18 others]

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

People

(Reporter: wpt-sync, Unassigned)

References

Details

(Whiteboard: [wpt])

Syncing wpt PR 53444 found new untriaged test failures in CI

Tests Affected

Firefox-only failures

CI Results

Missing results from treeherder
GitHub PR Head

Notes

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

Hi Jonathan - these failures seem to have come from your upstream "Don't try to use Ahem via src:local() in fonts/ahem.css" PR. I think we weren't expecting any behavior-change here, per
https://github.com/web-platform-tests/wpt/pull/53444#issuecomment-3049487343
https://github.com/web-platform-tests/wpt/pull/53444#pullrequestreview-2976147138

Do you know what happened here? (Probably this can be triaged as S3, but want to make sure nothing went amiss with the PR here...)

Flags: needinfo?(jfkthame)

(Same question goes for the other dependencies of bug 1976337, which is the bug about syncing that PR down. Apparently it caused new failures in a bunch of directories.)

The upstream PR looks ok, afaics.

I'm a bit puzzled by the report here, though. Taking /css/css-inline/text-box-trim/border-padding-001.html, for example, we have it annotated as expected-fail in testing/web-platform/meta/css/css-inline/text-box-trim/border-padding-001.html.ini ever since bug 1927454 (in October last year). So this isn't a new failure; why is it being reported here?

The same applies to a bunch of others (I haven't checked each one individually).

Flags: needinfo?(jfkthame)

Oh yeah, you're right. https://searchfox.org/mozilla-central/source/testing/web-platform/meta/css/css-inline/text-box-trim/border-padding-001.html.ini was last-edited in Oct last year.

And the commit on Bug 1976337 didn't touch that .ini file or indeed any .ini file:
https://hg-edge.mozilla.org/mozilla-central/rev/bed33c10ae74

So it seems the wpt-sync bot went a bit haywire here in filing 9 "New wpt failures" bugs hanging off of bug 1976337 (which in fact didn't add any new annotations for any new WPT failures).

jgraham, do you know what went wrong here? Probably someone who works on the wpt-sync-bot should take a look at bug 1976337 and figure out why/how it decided to file all of the dependent bugs there, for a PR-sync that didn't actually end up adding any new WPT expected-failure annotations...

[In any case, I'll triage the WPT failures here as S4, since they're not new. :) ]

Severity: -- → S4
Flags: needinfo?(james)

I'm not sure what happened here. It looks like at some point the bot thought these were new tests that failed. I think that could occur if it failed to download the results from the baseline runs for some reason. Those results do seem to be on wpt.fyi, but of course it's possible there was some temporary problem that meant we failed to fetch them.

Flags: needinfo?(james)
You need to log in before you can comment on or make changes to this bug.