Bug 1261842 - browser_bug495058.js no longer needs to wait for remoteness flip on initial browser of new window. r=Felipe,Gijs

MozReview-Commit-ID: Fl1OIsluS56

--HG--
extra : rebase_source : 699aece7ecef46b0a33af91356817b48473ad81e
extra : source : 8d34b61fbfb395d6816c45dcc1f45901e627c478
This commit is contained in:
Mike Conley 2016-06-08 16:42:04 -04:00
parent 276c6f9b96
commit 500f87700c

View File

@ -28,16 +28,6 @@ add_task(function*() {
TestUtils.topicObserved("browser-delayed-startup-finished",
subject => subject == win);
if (gMultiProcessBrowser &&
E10SUtils.canLoadURIInProcess(uri, Ci.nsIXULRuntime.PROCESS_TYPE_CONTENT)) {
// Until bug 1261842 is fixed, the initial browser is going to be
// non-remote. If we're transitioning to a URL that can be loaded
// remotely, we'll need to wait until that remoteness switch is done
// before we send any framescripts down to the browser.
yield BrowserTestUtils.waitForEvent(tab, "TabRemotenessChange");
contentPainted = BrowserTestUtils.contentPainted(tab.linkedBrowser);
}
yield Promise.all([delayedStartup, contentPainted]);
Assert.equal(win.gBrowser.currentURI.spec, uri, uri + ": uri loaded in detached tab");