Bug 1261842 - browser_bug495058.js no longer needs to wait for remoteness flip on initial browser of new window. r?felipe
MozReview-Commit-ID: Fl1OIsluS56
--- a/browser/base/content/test/general/browser_bug495058.js
+++ b/browser/base/content/test/general/browser_bug495058.js
@@ -23,26 +23,16 @@ add_task(function*() {
// browser element. We'll handle the e10s case in the next block.
let contentPainted = BrowserTestUtils.waitForEvent(tab.linkedBrowser,
"MozAfterPaint");
let delayedStartup =
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");
Assert.equal(win.document.activeElement, win.gBrowser.selectedBrowser, uri + ": browser is focused");
Assert.equal(win.gURLBar.value, "", uri + ": urlbar is empty");
Assert.ok(win.gURLBar.placeholder, uri + ": placeholder text is present");
yield BrowserTestUtils.closeWindow(win);