1888130 - New wpt failures in /css/css-anchor-position/position-try-cascade.html

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

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

Syncing wpt PR 45172 found new untriaged test failures in CI

Tests Affected

New Tests That Don't Pass

• /css/css-anchor-position/position-try-cascade.html [wpt.fyi]
  • @position-try rule applies: FAIL (Chrome: PASS, Safari: FAIL)
  • @position-try rule wins over inline style: FAIL (Chrome: PASS, Safari: FAIL)
  • @position-try rule does not win over !important: FAIL (Chrome: PASS, Safari: FAIL)
  • @position-try rule does not win over animations: FAIL (Chrome: PASS, Safari: FAIL)
  • @position-try rule does not win over transitions: FAIL (Chrome: PASS, Safari: FAIL)

CI Results

Gecko CI (Treeherder)
GitHub PR Head

Notes

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

Nowadays we only fail one subtest (of six):

@position-try rule does not win over transitions

FAIL message: assert_equals: expected 30 but got 5

It looks like the testcase is expecting that element to start at its --pf {-granted top: 50px; value and snap halfway to the target top: 10px function (using the "steps" easing function in the transition styling).

But for whatever reason, we're instead starting that element at its top: 0 value that's granted by the .abs { class, and we're transitioning it from there to top:10 (and correctly pausing halfway).

So the issue here isn't with the transition, but rather it's with figuring out that we should be triggering the position fallback.

Comment 2

[Daniel Holbert [:dholbert]]

Aha, further poking indicates that we do trigger the position fallback; we just don't end up using it as the start of the transition.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a reduced testcase.

When you click the button, Firefox moves the darkcyan element to near the very top of the pink shape; whereas Chrome moves it closer to halfway up.

Comment 4

[Daniel Holbert [:dholbert]]

Hmm, somehow we don't have this one annotated as failing in our own infrastructure. Bug 2006371 removed our failure annotation, but it still shows up as failing on wpt.fyi for some reason.

Emilio, you might be interested to take a look when you're back from PTO, given you worked on bug 2006371... Maybe there's some pref that we set for treeherder that's important here, and wpt.fyi doesn't benefit from it?

Comment 5

[Emilio Cobos Álvarez [:emilio]]

See https://github.com/web-platform-tests/wpt/pull/56868

Comment 6

[Daniel Holbert [:dholbert]]

Ah, right - thanks. Looks like maybe we need to poke someone over there... (not sure if an official test-change-proposal is merited or at least useful-to-get-the-ball-rolling)

Comment 7

[Daniel Holbert [:dholbert]]

Because, currently that PR has this status:

Merging is blocked
Waiting on code owner review from web-platform-tests/interop.

Comment 8

[Daniel Holbert [:dholbert]]

(restoring ni=emilio to [when back from PTO] create a test-change-proposal or do whatever poking might be worthwhile to un-stuck that PR)

Comment 9

[Emilio Cobos Álvarez [:emilio]]

I think there's no need for a test-change proposal, in the past someone from that group has just reviewed the changes (sometimes after some back and forth).