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
@@ -1766,17 +1766,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;