Bug 1355426 - Fix browser_bug495058.js to not wait for MozAfterPaint in non-remote browser case. r?jaws
I'm not sure why the non-remote browser case needed to wait for MozAfterPaint. In
the remote browser case, we do wait for MozAfterPaint in the content area before
focusing the URL bar, but in the non-e10s case, we just focus it right away.
MozReview-Commit-ID: gNsk8Oh6JO
--- a/browser/base/content/test/general/browser_bug495058.js
+++ b/browser/base/content/test/general/browser_bug495058.js
@@ -10,29 +10,30 @@ const URIS = [
];
add_task(async function() {
for (let uri of URIS) {
let tab = BrowserTestUtils.addTab(gBrowser);
await BrowserTestUtils.loadURI(tab.linkedBrowser, uri);
let win = gBrowser.replaceTabWithWindow(tab);
+
+ let contentPainted = Promise.resolve();
+ // In the e10s case, we wait for the content to first paint before we focus
+ // the URL in the new window, to optimize for content paint time.
+ if (tab.linkedBrowser.isRemoteBrowser) {
+ contentPainted =
+ BrowserTestUtils.waitForContentEvent(tab.linkedBrowser, "MozAfterPaint");
+ }
+
await TestUtils.topicObserved("browser-delayed-startup-finished",
subject => subject == win);
+ await contentPainted;
tab = win.gBrowser.selectedTab;
- // BrowserTestUtils doesn't get the add-on shims, which means that
- // MozAfterPaint won't get shimmed over if we add an event handler
- // for it in the parent.
- if (tab.linkedBrowser.isRemoteBrowser) {
- await BrowserTestUtils.waitForContentEvent(tab.linkedBrowser, "MozAfterPaint");
- } else {
- await BrowserTestUtils.waitForEvent(tab.linkedBrowser, "MozAfterPaint");
- }
-
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");
await BrowserTestUtils.closeWindow(win);
}
});