Bug 1213650 - Reloading (F5) loads about:blank instead of current page
Okay, I think I know how this is working...
Initial browser is non-remote by default.
We attempt to load about:home, and compute that we need to do a
remoteness switch on about:home. Parent does remoteness switch,
which starts a navigateAndRestore on the initial browser. This
starts a browser flush.
Flush finishes. We start to restore the history (which is basically
about:blank) for the newly remote browser by sending down a message with
the history to restore.
User puts in remote URL to load and presses ENTER. This sends down a message to load the URI.
Content starts restoring the content by loading about:home, but this is
suddenly cancelled with the newly entered URL from the user.
Mossop’s patch interprets the cancellation of that about:home load, and
calls restoreTabContent again, but without loadArguments… this will
cause us to restore the current history entry (which I guess is
“about:blank”?)
Content starts loading URL...
AHHH - navigateAndRestore looks like the culprit here. Multiple calls
can come into it before the first tab flush finishes - and so we end up
attempting two restores. Making this thing stash the last loadArguments
seems to work - and I have a regression test!
Hm… that didn’t fix it. Shit.
Okay, added logging on slow-mo machine. Here’s what I’ve found out:
ContentRestore.restoreTabContent is called with load arguments of
{
“uri”: “about:home”,
“flags”: 0,
“referrer”: null,
“referrerPolicy”: 0
}
And get this - the tab data entries array is:
{
“url”: “about:blank”,
“charset”: “”,
“ID”: 1,
“docshellID”: 5,
“docIdentifier”: 1,
“persist”: false
}
restoreTabContentStarted gets called, starts loading the document
AND THEN the new URI gets sent down, so we see a stop request
So restoreTabContentStarted completes with the abort state
And THAT triggers a recall to restoreTabContent with the same old values, except no load arguments.
YES! Finally a test case on my Windows box! THANK GOODNESS.
Okay! Movement on this. Apparently this is still an issue with bug
1175267 backed out, but its rarer. My patch for this bug put the issue
back into the “rare” bucket. I’ve filed bug 1226657 about the rare
bucket, with the following info:
"This presents exactly like
bug 1213650
, but seems to be much rarer. The conclusion that we came to in
bug 1213650
is that
bug 1175267
(which was originally identified as the regressing bug for
bug 1213650
) exacerbated a pre-existing problem, and made it more likely to occur.
This test is for the more unlikely (but still possible) case.
This test is for the more unlikely (but still possible) case.
I've written a test case, which I'll attach to this bug."
Sweet! Landed on integration.