Bugzilla

Looking at the last few failures here, it looks like they happen after we hit this early-finish() call:
https://searchfox.org/mozilla-central/rev/54c9b4896fdc1e858cd4942f306d877f1f3d195e/dom/animation/test/mozilla/file_restyles.html#148-150

And indeed, it looks like there's nothing stopping the test logic from proceeding to do more tests after we call finish() there.  We make a bunch of calls to `add_task` up-front, the first of which has this early-finish(), and the subsequent ones have additional `ok(...)` tests, and there's nothing stopping us from proceeding with those later tasks that have already been queued up.

I think the right fix here is to prevent ourselves from calling `add_tasks` for those later tasks, if we happen to take the early `finish()`.  I'm not sure if that's doable with add_task (e.g. if you can make `add_task` operations conditional on earlier `add_task` work), but if you can, that's probably the thing to do here.

Alternately, we could set some flag in our early-finish() logic, and then locally-redefine ok/is/etc. to check that flag before performing any actual comparison. But that's probably unnecessary hacky/complex.

Looking at the last few failures here, it looks like they happen after we hit this early-finish() call:
https://searchfox.org/mozilla-central/rev/54c9b4896fdc1e858cd4942f306d877f1f3d195e/dom/animation/test/mozilla/file_restyles.html#148-150
```html
if (vsyncRate > 40 - 5) {
  ok(true, `the vsync rate ${vsyncRate} on this machine is too slow to run this test`);
  SimpleTest.finish();
```
And indeed, it looks like there's nothing stopping the test logic from proceeding to do more tests after we call finish() there.  We make a bunch of calls to `add_task` up-front, the first of which has this early-finish(), and the subsequent ones have additional `ok(...)` tests, and there's nothing stopping us from proceeding with those later tasks that have already been queued up.

I think the right fix here is to prevent ourselves from calling `add_tasks` for those later tasks, if we happen to take the early `finish()`.  I'm not sure if that's doable with add_task (e.g. if you can make `add_task` operations conditional on earlier `add_task` work), but if you can, that's probably the thing to do here.

Alternately, we could set some flag in our early-finish() logic, and then locally-redefine ok/is/etc. to check that flag before performing any actual comparison. But that's probably unnecessary hacky/complex.

Looking at the last few failures here, it looks like they happen after we hit this early-finish() call:
https://searchfox.org/mozilla-central/rev/54c9b4896fdc1e858cd4942f306d877f1f3d195e/dom/animation/test/mozilla/file_restyles.html#148-150
```html
if (vsyncRate > 40 - 5) {
  ok(true, `the vsync rate ${vsyncRate} on this machine is too slow to run this test`);
  SimpleTest.finish();
```
And indeed, it looks like there's nothing stopping the test logic from proceeding to do more tests after we call finish() there.  We make a bunch of calls to `add_task` up-front, the first of which has this early-finish(), and the subsequent ones have additional `ok(...)` tests; and when we call `finish()`, there's nothing stopping us from proceeding with those later tasks that have already been queued up.

I think the right fix here is to prevent ourselves from calling `add_tasks` for those later tasks, if we happen to take the early `finish()`.  I'm not sure if that's doable with add_task (e.g. if you can make `add_task` operations conditional on earlier `add_task` work), but if you can, that's probably the thing to do here.

Alternately, we could set some flag in our early-finish() logic, and then locally-redefine ok/is/etc. to check that flag before performing any actual comparison. But that's probably unnecessary hacky/complex.