Bug 1317212 - <xul:browser>'s that flip remoteness should not send progress updates for the initial about:blank load. r=Gijs
authorMike Conley <mconley@mozilla.com>
Mon, 28 Nov 2016 14:46:26 -0500
changeset 463169 1b00058c2288f0c41fde073ef20cf5dc2be26011
parent 463168 8d8e6116ed6ddbd99a528fcd8911e559336b938f
child 463170 92f50b968d7f7a1ae22fd15ff95d6072cca06c6c
push id41967
push userbmo:miket@mozilla.com
push dateWed, 18 Jan 2017 15:17:32 +0000
bugs1317212, 1254669
Bug 1317212 - <xul:browser>'s that flip remoteness should not send progress updates for the initial about:blank load. r=Gijs This is kind of a sad story. In bug 1254669, I made it so that we destroy the original tab progress listener and create a new one when flipping remoteness. This is because the initial about:blank load for a flipped browser is not something we ever want to show progress for. I goofed though*, and didn't call the mTabProgressListener constructor with the right argument that indicates that the first messages are from about:blank. This opened us up for a race with e10s-mode where, after a tab tear out, the initial browser would flip remoteness to remote, send up a StateChange message to indicate loading of about:blank (which we'd accidentally listen to). The race happened when we'd sometimes do the frameloader swap before the StateChange to indicate that about:blank had finished loading would come up. This would mean (after the frameloader swap), we'd never hear about the initial about:blank finishing loading, so we'd always show "busy". * :( MozReview-Commit-ID: 6pU1fqiIDUc
--- a/browser/base/content/tabbrowser.xml
+++ b/browser/base/content/tabbrowser.xml
@@ -1767,17 +1767,17 @@
             // As frameLoaders start out with an active docShell we have to
             // deactivate it if this is not the selected tab's browser or the
             // browser window is minimized.
             aBrowser.docShellIsActive = this.shouldActivateDocShell(aBrowser);
             // Create a new tab progress listener for the new browser we just injected,
             // since tab progress listeners have logic for handling the initial about:blank
             // load
-            listener = this.mTabProgressListener(tab, aBrowser, false, false);
+            listener = this.mTabProgressListener(tab, aBrowser, true, false);
             this._tabListeners.set(tab, listener);
             filter.addProgressListener(listener, Ci.nsIWebProgress.NOTIFY_ALL);
             // Restore the progress listener.
             aBrowser.webProgress.addProgressListener(filter, Ci.nsIWebProgress.NOTIFY_ALL);
             // Restore the securityUI state.
             let securityUI = aBrowser.securityUI;