Archive for December, 2015
I was working on another bug the other day when I came across a disabled test. The comment for why it was disabled seemed like it might be low-hanging fruit for conversion to be
e10s-compatible, so I took a look.
A couple of things leapt out to me immediately: the test isn’t using
BrowserTestUtils and it isn’t using promises. So, the first step is to convert it to use
Promise. Here’s the diff.
Now that we’re using promises and the nice helpers, let’s see why the test isn’t compatible. The first load is of a
chrome:// URL. This is guaranteed to load in the parent, meaning that our first test,
testXFOFrameInChrome can remain untouched. We can use its
contentWindow with impunity.
The second test,
testXFOFrameInContent is the reason this blog post exists. It loads a content document, meaning that its browser will be a remote browser and the
contentWindow would be a CPOW. Instead of using it directly, we can use another helper:
ContentTask. This will let us perform an operation in a given
browser‘s associated child process and fulfill a
Promise when it finishes. Here’s that change.
We’re almost done! However, if we run this version, we’ll still fail due to a small difference between the function
is in browser-chrome tests and in
ContentTask.jsm. The version in
ContentTask.jsm is stricter than that of the normal tests, so when we check the return value of
undefined we get a test failure. We fix that by checking against the correct value (
null). Another thing to note is that
ContentTask decompiles and recompiles the callback function in the child process. That means that you can’t use any global variables or functions. You can pass a single parameter to the function, though, as long as it can be structured cloned. The content window is available through the
content global in frame scripts.
One last note about this test. When I was writing it, I used
BrowserTestUtils.loadURI function which returns a
Promise. However, that promise doesn’t resolve when the URI is loaded, only when the load starts. So I ended up wasting a bunch of time before realizing that I needed to use
BrowserTestUtils.browserLoaded after it to ensure the second test runs at the right time.
Now, our test passes and we can get it reviewed and checked in!