1979297 - Several Windows opt failures after the latest wpt-sync

Status: REOPENED

(Testing :: web-platform-tests, defect)

Description

[Serban Stanca [:SerbanS]]

Hi Alexandra! Could you please take a look at these wpt failures? It seems that they're a fallout of the latest wpt-sync and they're failling in every instance but with several failure lines, as it can be seen here. This is happening only on Autoland. A separate instance it's happening on main too but on Windows 11 24H2 Shippable, as it can be seen here.

Thank you!

Comment 1

[Alexandra Borovova [:Sasha]]

Attachment: Bug 1979297 - Remove unneeded metadata for event-timing/click.html.

Comment 2

[Alexandra Borovova [:Sasha]]

I can see that /event-timing/click.html failures come from wptsync landing, but I'm not sure about everything else. I've created the patch for /event-timing/click.html.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a12fdadabe88
https://hg.mozilla.org/integration/autoland/rev/c39093d31d5e
Remove unneeded metadata for event-timing/click.html.

Comment 4

[Cristina Horotan [:chorotan]]

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

Comment 5

[Intermittent Failures Robot]

65 failures were associated with this bug yesterday.

Repository breakdown:

• autoland: 60
• try: 3
• mozilla-central: 2

Table

	headless	no_variant	pb-s
windows11-x86/opt		1
windows11-x86_64/opt	1	62	1

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1979297&startday=2025-07-25&endday=2025-07-25&tree=all

Comment 6

[Serban Stanca [:SerbanS]]

The failures in /event-timing/click.html indeed seem to have been resolved but the other failures are still present. After some more digging, Bug 1937025 looks to be the one who started this, as it can be seen in these ranges of retriggers and backfills: r1, r2, r3.

Hi Bob! Could you please take a look at this?

Thank you!

Comment 7

[Bob Owen (:bobowen)]

I've run those jobs 5 times each on my final try push and didn't get any failures, so I'm a bit confused as to why these changes could have caused those failures.
https://treeherder.mozilla.org/jobs?repo=try&duplicate_jobs=visible&revision=a7b3fcfa81b63b10747c27fdb7e77b8a08371c66

Comment 8

[Bob Owen (:bobowen)]

Pushed central and with the main patch from bug 1937025 backed out to try:
https://treeherder.mozilla.org/jobs?repo=try&revision=bbe636c27daa704736b76524dd0c809d4e86e89f
https://treeherder.mozilla.org/jobs?repo=try&revision=c554116ff2854fd88e3c7b1f7c4b2e5b2b20d213

There do appear to be fewer failures with the back-out.
One of the issues is that we don't seem to get crash dumps a lot of the time.
When we do, the failures seem to be bug 1979494 and bug 1977225.
Crashing here for 1979494 because oldCurrentEntry is null.
Crashing here for 1977225.

Looking at the dumps, the root cause in both cases seems to be GetCurrentEntry returning null because mCurrentEntryIndex is not set.

Hard to see why the chromium sandbox update would actually cause these failures, so perhaps it is some sort of timing issue.
smaug - what do you think?
Can these be fixed by null checks or is there a deeper issue?

Comment 9

[Intermittent Failures Robot]

85 failures were associated with this bug in the last 7 days.
This is the #22 most frequent failure this week.

This failure happened more than 75 times this week! Resolving this bug is a very high priority.

Try to resolve this bug as soon as possible. If unresolved for 1 week, the affected test(s) may be disabled.

Repository breakdown:

• autoland: 80
• try: 3
• mozilla-central: 2

Table

	headless	no_variant	pb-s
windows11-x86/opt		1
windows11-x86_64/opt	1	82	1

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1979297&startday=2025-07-21&endday=2025-07-27&tree=all

Comment 10

[Intermittent Failures Robot]

25 failures were associated with this bug yesterday.

Repository breakdown:

• autoland: 25

Table

	no_variant
windows11-x86_64/opt	25

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1979297&startday=2025-07-28&endday=2025-07-28&tree=all

Comment 11

[Bob Owen (:bobowen)]

Given that there didn't appear to be an issue on my final try push, I've bisected on try to find what else it is interacting with to cause the failures.
It ends up on Bug 1977364 - Remove support for ducktyped errors.
Try push with my changes on top of first patch for that bug:
https://treeherder.mozilla.org/jobs?repo=try&revision=1523186cd8154e066d337bcca2adc919c8a756f4
Try push on top of second patch:
https://treeherder.mozilla.org/jobs?repo=try&revision=463208c564e47e1102ac8d629a3c98c08d1bd873

So, I've pushed two more try runs with current central and the pref set to true and both patches backed out:
https://treeherder.mozilla.org/jobs?repo=try&revision=a101b1c8f4720fd2b015ec670ea01753ac39904b
https://treeherder.mozilla.org/jobs?repo=try&revision=1774847716012e2757588acbede05b26670348f9

Looks like both of these resolve the crashes.
tschuster: any idea how these might interact?
In theory there shouldn't be any sandboxing changes here, but there could of course be timing changes.

The chromium update also produced some memory improvements: bug 1937025 comment 42.

Comment 12

[Serban Stanca [:SerbanS]]

FWIW, this seems to be resolved now. The last push where these failures appeared was this one. What came after that were clear from these failures.

Comment 13

[Bob Owen (:bobowen)]

(In reply to Serban Stanca [:SerbanS] from comment #12)

FWIW, this seems to be resolved now. The last push where these failures appeared was this one. What came after that were clear from these failures.

Seems it's still failing on some builds:
https://treeherder.mozilla.org/jobs?repo=autoland&revision=ba74f4e0d9bfcdbb4c2e3ec2267632a65dd8a2d5
https://treeherder.mozilla.org/jobs?repo=autoland&revision=d970c2612f53e692c05a34890ea5896f30ed5593

There are clean ones either side of these.

Comment 14

[Tom Schuster (MoCo)]

Sorry, I have no idea why this would crash. It's of course problem that we changed the reported error message somewhere and the code can't deal? Is this is even a "real" crash?

INFO - NoSuchWindowException on command, setting status to CRASH
INFO - TEST-UNEXPECTED-CRASH | /html/document-isolation-policy/credentialless-shared-worker.https.tentative.window.html?request_origin=same_origin&worker_dip=none&window_dip=none | expected OK
INFO - TEST-INFO took 805ms
INFO - PID 8384 | JavaScript error: chrome://remote/content/shared/webdriver/Certificates.sys.mjs, line 79: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsICertOverrideService.setDisableAllSecurityChecksAndLetAttackersInterceptMyData]
INFO - Browser exited with return code 572

Comment 15

[Intermittent Failures Robot]

26 failures were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 26

Table

	no_variant
windows11-x86_64/opt	26

For more details, see:

https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1979297&startday=2025-07-28&endday=2025-08-03&tree=all

Comment 16

[Tom Schuster (MoCo)]

So it does still happen. I don't really know how to proceed here.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

farre, see comment 8.
Need to get some Navigation API crashes fixed ;)

Comment 18

[Andreas Farre [:farre]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #17)

farre, see comment 8.
Need to get some Navigation API crashes fixed ;)

Yeah, looking at it now. It's not a null check that's needed, it's a deeper issue.

Comment 19

[Tom Schuster (MoCo)]

I had another look at this. The following failure in Bob's Try push seems interesting:

TEST-UNEXPECTED-FAIL | /workers/interfaces/WorkerUtils/importScripts/report-error-cross-origin.sub.any.worker.html | WorkerGlobalScope error event: lineno - assert_equals: expected 8 but got 0
TEST-UNEXPECTED-FAIL | /workers/interfaces/WorkerUtils/importScripts/report-error-cross-origin.sub.any.sharedworker.html | WorkerGlobalScope error event: filename - assert_equals: expected "http://web-platform.test:8000/workers/interfaces/WorkerUtils/importScripts/report-error-helper.js" but got "" 

These exact symptoms happen when JS::ErrorReportBuilder::maybeCreateReportFromDOMException returns nullptr. Of course it's not clear why this would happen non-deterministically. The ini file for this test does that show that even before my changes it seems to be highly unreliable.