{"id":127,"date":"2015-12-10T09:26:09","date_gmt":"2015-12-10T16:26:09","guid":{"rendered":"http:\/\/blog.mozilla.org\/mrbkap\/?p=127"},"modified":"2015-12-10T09:26:09","modified_gmt":"2015-12-10T16:26:09","slug":"converting-a-test-to-be-e10s-compatible","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/mrbkap\/2015\/12\/10\/converting-a-test-to-be-e10s-compatible\/","title":{"rendered":"Converting a test to be e10s compatible"},"content":{"rendered":"<p>I was working on another bug the other day when I came across <a href=\"https:\/\/dxr.mozilla.org\/mozilla-central\/rev\/a8965ae93c5d098a4f91ad9da72150bb43df07a7\/dom\/base\/test\/browser.ini#15\">a disabled test<\/a>. The comment for why it was disabled seemed like it might be low-hanging fruit for conversion to be <code>e10s<\/code>-compatible, so I took a <a href=\"https:\/\/github.com\/mrbkap\/e10s-test-explainer-repo\/blob\/955de1c75668f6312b9ce1109655c74cb33e6570\/browser_bug593387.js\">look.<\/a> <\/p>\n<p>A couple of things leapt out to me immediately: the test isn&#8217;t using <a href=\"https:\/\/dxr.mozilla.org\/mozilla-central\/source\/testing\/mochitest\/BrowserTestUtils\/BrowserTestUtils.jsm\"><code>BrowserTestUtils<\/code><\/a> and it isn&#8217;t using promises. So, the first step is to convert it to use <code>BrowserTestUtils<\/code> and <code>Promise<\/code>. Here&#8217;s <a href=\"https:\/\/github.com\/mrbkap\/e10s-test-explainer-repo\/commit\/6f1a2004f909891d302dc5c02f4c0c4b67bd8ba0\">the diff.<\/a><\/p>\n<p>Now that we&#8217;re using promises and the nice helpers, let&#8217;s see why the test isn&#8217;t compatible. The <a href=\"https:\/\/github.com\/mrbkap\/e10s-test-explainer-repo\/blob\/6f1a2004f909891d302dc5c02f4c0c4b67bd8ba0\/browser_bug593387.js#L11\">first load<\/a> is of a <code>chrome:\/\/<\/code> URL. This is guaranteed to load in the parent, meaning that our first test, <code>testXFOFrameInChrome<\/code> can remain untouched. We can use its <code>contentWindow<\/code> with impunity.<\/p>\n<p>The second test, <code>testXFOFrameInContent<\/code> is the reason this blog post exists. It loads a content document, meaning that its browser will be a remote browser and the <code>contentWindow<\/code> would be a <a href=\"https:\/\/billmccloskey.wordpress.com\/2013\/12\/05\/multiprocess-firefox\/#cpows\">CPOW.<\/a> Instead of using it directly, we can use another helper: <a href=\"https:\/\/dxr.mozilla.org\/mozilla-central\/rev\/319be5e7ce3061c7c16f24d750b6dacdbcac4c35\/testing\/mochitest\/BrowserTestUtils\/ContentTask.jsm\"><code>ContentTask<\/code>.<\/a> This will let us perform an operation in a given <code>browser<\/code>&#8216;s associated child process and fulfill a <code>Promise<\/code> when it finishes. Here&#8217;s <a href=\"https:\/\/github.com\/mrbkap\/e10s-test-explainer-repo\/commit\/a2b7679bbf3a9e0d41c567ddf6b2ead3bb90c75e\">that change<\/a>.<\/p>\n<p>We&#8217;re almost done! However, if we run this version, we&#8217;ll still fail due to a small difference between the function <code>is<\/code> in browser-chrome tests and in <code>ContentTask.jsm<\/code>. The version in <code>ContentTask.jsm<\/code> is stricter than that of the normal tests, so when we check the return value of <code>document.getElementById<\/code> against <code>undefined<\/code> we get a test failure. We fix that by <a href=\"https:\/\/github.com\/mrbkap\/e10s-test-explainer-repo\/commit\/11482a63a05b4aba39a2469ea01c0e06d5de614c\">checking against the correct value<\/a> (<code>null<\/code>). Another thing to note is that <code>ContentTask<\/code> decompiles and recompiles the callback function in the child process. That means that you can&#8217;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 <code>content<\/code> global in frame scripts.<\/p>\n<p>One last note about this test. When I was writing it, I used <code>BrowserTestUtils.loadURI<\/code> function which returns a <code>Promise<\/code>. However, that promise doesn&#8217;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 <code>BrowserTestUtils.browserLoaded<\/code> after it to ensure the second test runs at the right time.<\/p>\n<p>Now, our test passes and we can get it <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=1231695\">reviewed and checked in!<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8217;t using BrowserTestUtils and [&hellip;]<\/p>\n","protected":false},"author":149,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/posts\/127"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/users\/149"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/comments?post=127"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/posts\/127\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/media?parent=127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/categories?post=127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/mrbkap\/wp-json\/wp\/v2\/tags?post=127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}