Closed Bug 1895554 Opened 1 year ago Closed 1 year ago

Intermittent /css/css-contain/content-visibility/animation-display-lock.html | single tracking bug

Categories

(Core :: Layout, defect, P5)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure, intermittent-testcase)

Filed by: tszentpeteri [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=457308931&repo=mozilla-central
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/EsBOJD5RRWupDpBDqNUyaA/runs/0/artifacts/public/logs/live_backing.log

[task 2024-05-07T17:00:24.133Z] 17:00:24     INFO - TEST-START | /css/css-transitions/KeyframeEffect-getKeyframes.tentative.html
[task 2024-05-07T17:00:24.159Z] 17:00:24     INFO - Closing window df5c20c1-f358-4712-a31d-44fb0a78991c
[task 2024-05-07T17:00:24.183Z] 17:00:24     INFO - PID 26836 | [Child 27138, Main Thread] WARNING: could not set real-time limit in CubebUtils::InitLibrary: file /builds/worker/checkouts/gecko/dom/media/CubebUtils.cpp:757
[task 2024-05-07T17:00:24.521Z] 17:00:24     INFO - 
[task 2024-05-07T17:00:24.522Z] 17:00:24     INFO - TEST-UNEXPECTED-TIMEOUT | /css/css-contain/content-visibility/animation-display-lock.html | Animation events do not fire for a CSS animation running in a display locked subtree - Test timed out
[task 2024-05-07T17:00:24.523Z] 17:00:24     INFO - 
[task 2024-05-07T17:00:24.523Z] 17:00:24     INFO - TEST-UNEXPECTED-NOTRUN | /css/css-contain/content-visibility/animation-display-lock.html | The finished promise does not resolve due to the normal passage of time  for a CSS animation in a display locked subtree - expected PASS
[task 2024-05-07T17:00:24.524Z] 17:00:24     INFO - 
[task 2024-05-07T17:00:24.524Z] 17:00:24     INFO - TEST-UNEXPECTED-NOTRUN | /css/css-contain/content-visibility/animation-display-lock.html | The finished promise does not resolve due to the normal passage of time  for a CSS transition in a display locked subtree - expected PASS
[task 2024-05-07T17:00:24.524Z] 17:00:24     INFO - 
[task 2024-05-07T17:00:24.524Z] 17:00:24     INFO - TEST-UNEXPECTED-NOTRUN | /css/css-contain/content-visibility/animation-display-lock.html | Events and promises are handled normally for animations without an owning element - expected PASS
[task 2024-05-07T17:00:24.524Z] 17:00:24     INFO - TEST-UNEXPECTED-TIMEOUT | /css/css-contain/content-visibility/animation-display-lock.html | expected OK
[task 2024-05-07T17:00:24.524Z] 17:00:24     INFO - TEST-INFO took 31766ms
[task 2024-05-07T17:00:24.526Z] 17:00:24     INFO - PID 26229 | 1715101224525	Marionette	INFO	Stopped listening on port 55664
[task 2024-05-07T17:00:24.754Z] 17:00:24     INFO - ....
[task 2024-05-07T17:00:24.754Z] 17:00:24     INFO - TEST-OK | /css/css-transitions/KeyframeEffect-getKeyframes.tentative.html | took 619ms
[task 2024-05-07T17:00:24.754Z] 17:00:24     INFO - TEST-START | /css/css-transitions/KeyframeEffect-setKeyframes.tentative.html

This started to fail on Tier 1.

Summary: Intermittent [tier 2] /css/css-contain/content-visibility/animation-display-lock.html | single tracking bug → Intermittent /css/css-contain/content-visibility/animation-display-lock.html | single tracking bug

I just pushed a try build with all the expectations removed, and Marionette trace logs enabled. Lets see what this might be:
https://treeherder.mozilla.org/jobs?repo=try&revision=643eb9841a6c4d693de748eb25f384117c81daa2

The hangs are actually caused by the lines for waitForEvent(target, 'animationiteration'). As for the failing tests the event is never received.

Daniel, do you have an idea why this could be the case?

This failure might have been shadowed before due to race conditions for the testrunner and bug 1522790 changed that.

Flags: needinfo?(dholbert)

I don't have any ideas for an explanation, offhand. The test seems to pass locally for me, for what it's worth.

If I'm reading the .ini file correctly...
https://searchfox.org/mozilla-central/rev/1b90936792b2c71ef931cb1b8d6baff9d825592e/testing/web-platform/meta/css/css-contain/content-visibility/animation-display-lock.html.ini
...it looks like this test is annotated as always timing out on TSAN, and sometimes timing out on ASAN, and sometimes timing out on debug builds.

The next question is whether the problem is us never sending the event at all, vs. if we just haven't yet managed to send the event by the time the test completes (due to TSAN/ASAN overhead or something).

Could you retry your Try Run with this added near the top of this test's html, to give it a longer timeout threshold?

<meta name="timeout" content="long">

(e.g. inserted right after the utf-8 charset line here: https://searchfox.org/mozilla-central/rev/1b90936792b2c71ef931cb1b8d6baff9d825592e/testing/web-platform/tests/css/css-contain/content-visibility/animation-display-lock.html#2 )

Depending on whether or not that helps, that'll give us a clue about what sort of problem we're dealing with.

Flags: needinfo?(dholbert) → needinfo?(hskupin)

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

Could you retry your Try Run with this added near the top of this test's html, to give it a longer timeout threshold?

<meta name="timeout" content="long">

Sure! Here a try build with the timeout extended:
https://treeherder.mozilla.org/jobs?repo=try&revision=50e8392f6b4213d94b5fbbe0ec5f74ba23cd2da1

Flags: needinfo?(hskupin)

As it looks like it's actually intermittently failing. If it passes the event comes through immediately (see wpt21), but in other cases we timeout after 3 minutes (wpt19). So maybe it's related to the test order or which test is actually selected to run before?

I think in all of these logs, this test is the only test that gets run -- there's only one TEST-START line in the log. So I suspect there's no meaningful difference between wpt19 and wpt21 there (not sure how/why we ended up with both for this try run; shrug).

After some retriggers, it looks like this is indeed just a "regular" intermittent failure.

I think it's a test bug. The test has some hardcoded animation durations that are suspiciously short (1s long), from the perspective of a bogged-down TSAN/ASAN build.

If I make those animations 1/10th as long (0.1s), then I can reproduce the TIMEOUT/NOTRUN failures locally, in Firefox and in Chrome.

So: I think the problem here is that the test is setting up those relatively-short animations and then those animations complete on their own before the test is ready for them to complete.

Likely we can address this by making the animations 10x as long. This shouldn't cause the test to take 10x as long, because the test programmatically seeks the animations to the relevant times that it wants to sample.

Depends on: 1922353

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

Likely we can address this by making the animations 10x as long. This shouldn't cause the test to take 10x as long, because the test programmatically seeks the animations to the relevant times that it wants to sample.

I've posted a patch to do that in helper-bug 1922353 (spun off as a helper so that this bug can continue tracking the intermittent in case there are still other intermittent failures here). It looks like it should remove all of the intermittent failures in this test; I was able to delete the associated .ini file and get green try results for the cf task.

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

I've posted a patch to do that in helper-bug 1922353 (spun off as a helper so that this bug can continue tracking the intermittent in case there are still other intermittent failures here). It looks like it should remove all of the intermittent failures in this test; I was able to delete the associated .ini file and get green try results for the cf task.

It seems to look all fine now. The failures stopped on October 3rd. Daniel, I assume that we can close this bug as WFM now given that no other work is needed?

Flags: needinfo?(dholbert)

Hooray! Yup.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.