Bugzilla

I guess the preexisting test `desktop-mode.html` itself will also now fail verification, specifically for the "run test 10 times in a row" etc.  The new expectation that I added to that test (that `forceDesktopViewport` is initially off) won't hold up on repeated runs of the test.  As above, we could relax this expectation in the test, but it's kind of nice as validation that the test pair as-a-whole are sound.

In a perfect world, we'd be able to make this reftest standalone and atomic by bundling the "cleanup" work (restoring `forceDesktopViewport`) to happen after the reftest snapshot. But I'm not sure we can arrange for that to happen; once the reftest snapshot has been taken, the test harness navigates away from the test and I don't think there's a way for a test to reliably schedule JS to run at that point.

I guess the preexisting test `desktop-mode.html` itself will also now fail verification, specifically for the "run test 10 times in a row" etc.  The new expectation that I added to that test (that `forceDesktopViewport` is initially off) won't hold up if the test is run in a loop (without its `-cleanup.html` buddy).  As above, we could relax this expectation in the test, but it's kind of nice as validation that the test pair as-a-whole are sound.

In a perfect world, we'd be able to make this reftest standalone and atomic by bundling the "cleanup" work (restoring `forceDesktopViewport`) to happen after the reftest snapshot. But I'm not sure we can arrange for that to happen; once the reftest snapshot has been taken, the test harness navigates away from the test and I don't think there's a way for a test to reliably schedule JS to run at that point.

I guess the preexisting test `desktop-mode.html` itself will also now fail verification, specifically for the "run test 10 times in a row" etc.  The new expectation that I added to that test (that `forceDesktopViewport` is initially off) won't hold up if the test is run in a loop (without its `-cleanup.html` buddy).  As above, we could relax this expectation in the test, but it's kind of nice as validation that the test pair as-a-whole are sound (i.e. that the value that we're setting in the cleanup test is in fact the original/default value).

In a perfect world, we'd be able to make this reftest standalone and atomic by bundling the "cleanup" work (restoring `forceDesktopViewport`) to happen after the reftest snapshot. But I'm not sure we can arrange for that to happen; once the reftest snapshot has been taken, the test harness navigates away from the test and I don't think there's a way for a test to reliably schedule JS to run at that point.

I guess the preexisting test `desktop-mode.html` itself will also now fail verification, specifically for the "run test 10 times in a row" etc.  The new expectation that I added to that test (that `forceDesktopViewport` is initially off) won't hold up if the test is run in a loop (without its `-cleanup.html` buddy).  As above, we could relax this expectation in the test, but it's kind of nice as validation that the test pair as-a-whole are sound (i.e. that the value that we're setting in the cleanup test is in fact the original/default value).

In a perfect world, we wouldn't need the separate `-cleanup.html` test file, and we'd be able to make this reftest standalone and atomic by bundling the "cleanup" work (restoring `forceDesktopViewport`) to happen after the reftest snapshot. But I'm not sure we can arrange for that to happen; once the reftest snapshot has been taken, the test harness navigates away from the test and I don't think there's a way for a test to reliably schedule JS to run at that point.

I guess the preexisting test `desktop-mode.html` itself will also now fail verification, specifically for the "run test 10 times in a row" etc.  The new expectation that I added to that test (that `forceDesktopViewport` is initially off) won't hold up if the test is run in a loop (without its `-cleanup.html` buddy).  As above, we could relax this expectation in the test, but it's kind of nice as validation that the test pair as-a-whole are sound (i.e. that the value that we're setting in the cleanup test is in fact the original/default value).

In a perfect world, we wouldn't need the separate `-cleanup.html` test file, and we'd be able to make this reftest standalone and atomic by scheduling the "cleanup" work (restoring `forceDesktopViewport`) to happen after the reftest snapshot. But I'm not sure we can arrange for that to happen; once the reftest snapshot has been taken, the test harness navigates away from the test and I don't think there's a way for a test to reliably schedule JS to run at that point.