[testharness.js] Ignore errors after completion

[jugglinmike]

Although uncaught exceptions are often an indication of errors in test design, the harness status cannot be safely modified following completion, so these exceptions must be ignored.

---

Here are some comparisons between test results collected from master and test results collected with this patch applied:

• Chrome: https://wpt.fyi/results/?diff&filter=ADC&run_id=348750003&run_id=345290003
• Firefox: https://wpt.fyi/results/?diff&filter=ADC&run_id=352460003&run_id=348770002

As usual, flaky tests make interpreting these comparisons a little tricky. Firefox's results don't seem to be influenced by this change, but Chrome's results have some differences.

I found 5 tests which report ERROR consistently in master and OK consistently with the patch applied.

• content-security-policy/script-src/script-src-strict_dynamic_hashes.html - this test has a bug which I've reported with this issue
• html/syntax/parsing/html5lib_innerHTML_adoption01.html - this test has a bug which I've tried to fix with this patch
• infrastructure/expected-fail/unhandled-rejection-following-subtest.html - this is a test for the behavior under consideration. I've added a "fixup!" commit to this branch to remove it
• mediacapture-image/MediaStreamTrack-getConstraints-fast.html - this test has a bug which I've tried to fix with this patch
• trusted-types/block-string-assignment-to-DOMWindowTimers-setTimeout-setInterval.tentative.html - this test intentionally triggers an uncaught exception, so it seems to expect the behavior proposed here. As a "tentative" test, it may be that the authors aren't yet scrutinizing the results on wpt.fyi

I found 5 tests which are flaky in master and consistent with the patch applied:

• content-security-policy/script-src/script-src-strict_dynamic_in_img-src.html
• html/webappapis/microtask-queuing/queue-microtask-exceptions.any.worker.html
• offscreen-canvas/* (coincidentally, we just recently recognized that these tests are invalid)
• workers/baseurl/alpha/sharedworker-in-worker.html
• workers/interfaces/WorkerGlobalScope/onerror/exception-in-onerror.html

If the effect of this change seems agreeable, I'd be happy to discuss alternative implementations. For instance, we could freeze the status object at the moment of completion, or we could call structured_clone (which would have a similar effect due to memoization).

[jugglinmike]

@gsnedders @jgraham Mind weighing in on this?

[jugglinmike]

This is hit during test collection, right? So this should still ERROR?

I assumed otherwise, but it looks like I was wrong.

When cleaning up after running a script, a browser is supposed to perform a microtask checkpoint, and that involves notifying about rejected promises. Since the load event doesn't fire until a couple tasks later (and since all of the relevant operations use the DOM Manipulation task source), it seems like we can expect the unhandledrejection event to occur before the harness has transitioned to the COMPLETE phase.

This event ordering is contentious, so I've submitted a test for it: #20329

[jugglinmike]

No description provided.

[jugglinmike]

No description provided.

[gsnedders]

If the effect of this change seems agreeable, I'd be happy to discuss alternative implementations. For instance, we could freeze the status object at the moment of completion, or we could call structured_clone (which would have a similar effect due to memoization).

I think I'd quite like to do both this and freeze as much as possible when we're done?

[jugglinmike]

That's actually one alternative I'm not comfortable with. If we use both solutions, then one will be untested, and the redundancy may confuse future contributors.