This changes them to return a promise that resolves when the work is done, but we still need to change the callers to handle this new return type and do the right thing when these functions do their work async-ly.

To do this we add a JSWindowActor called ReftestFission. reftest-content.js communicates with this actor via reftest.jsm.

Depends on D51342

The code comment mostly explains the design. Basically, we force nothing to happen while we wait for the promises to finish and instead record what we need to do once the promise is finished, and do those pending tasks when it's finished.

Depends on D51343

The long code comment explains.

Depends on D51344

I don't think this is strictly necessary but it lets us avoid a bunch of useless work, especially with webrender where these rects are always the full window size.

Depends on D51345

These tests test that moving around the plugin causes it to still draw correctly. If we don't have the test plugin then they fail and are marked as such.

The tests start by moving the plugin and then waiting for MozAfterPaint or MozPaintWaitFinished. When there is no plugin these events don't come.

Without the test plugin this was working because they got an unrelated MozAfterPaint (it was probably one of the early paints of the page).

After we update the reftest harness for fission and make it more async in general we no longer catch this early MozAfterPaint and the tests don't start.

We should just skip them, there is nothing to test with a plugin.

Depends on D51346

The asserts are

NS_ASSERTION(mDidInitialize, "should have done initial reflow by now");

in

layout/base/PresShell.cpp

in a couple of different places.

The stacks are slightly different from the existing case in bug 566159. In bug 566159 the stacks are as a result of asking to scroll. In this case the stacks are from an autofocus form element. The element is actually in our about:neterror page when the test tries to navigate to "href". The reason they show up now is that the Fission work on the reftest harness, in general, makes things more async. So in this test we previously tore down the page and moved on to the next test before being able to hit these assertions.

Depends on D51347

With the fission changes everything is more async, meaning some tests can run longer. Some crashtests navigate to a new location meaning the original root element we have a variable for is no longer around. When we try to access it we get an error saying we can't access a dead object.

Not all of these try catches are probably necessary but most of them are.

Depends on D51346

The changes to make the test harness avoid busy waiting with setTimeout(0)'s made this test fail on Android 8.0 debug webrender. In order to get an active layer the test tweaks a transform slightly that has no visual effect every 74 ms. This is necessary to test the bug as far as I can tell (I wrote the test). The test times out because MakeProgress never makes any progress, there is always an afterpaint pending or an after paint has fired and we need to update the canvas for it. The painting and running through the settimeouts etc of the reftest harness take slightly too long. Before the changes to remove the busy waits we were just barely passing this test, it took 76 seconds in once instance that I checked and hundreds of iterations before we could make progress. Haven't debugged exactly why removing the busywaits makes this fail but it doesn't seem important.

Depends on D52649

With the fission changes everything is more async, meaning some tests can run longer. Some crashtests navigate to a new location meaning the original root element we have a variable for is no longer around, and chrome isn't allowed to keep content nodes alive, so we are left holding a dead wrapper that throws if we try to access anything on it.

So we check if contentRootElement has become a dead wrapper (and null it out) any time we try to access it and it could have become dead. Generally the existing code already handled a null contentRootElement.

Depends on D52828

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Backed out 8 changesets (bug 1593170) for causing mass reftest failures. CLOSED TREE

Backout revision https://hg.mozilla.org/integration/autoland/rev/bdca724cf3a248e511fdc87c44f018f6287fa328

Failed push https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=2c98625f235b532d925f84e473406ff81e47d02e

Failure log https://treeherder.mozilla.org/logviewer.html#?job_id=276683927&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=276683961&repo=autoland

Timothy can you please take a look?

https://hg.mozilla.org/mozilla-central/rev/06f14f474f28
https://hg.mozilla.org/mozilla-central/rev/449d87c47593
https://hg.mozilla.org/mozilla-central/rev/ddcfa0a1fa00
https://hg.mozilla.org/mozilla-central/rev/285e9108032f
https://hg.mozilla.org/mozilla-central/rev/0dc7546c4a8a
https://hg.mozilla.org/mozilla-central/rev/249e26bfefd6
https://hg.mozilla.org/mozilla-central/rev/cd93c57f87fa
https://hg.mozilla.org/mozilla-central/rev/f663e895f995

Blocks enabling Fission in Nightly (M6)