This was interesting to debug, I think understand what's going on.
I diff'd the browser.xhtml source for about:robots from before and after restoring and the only relevant difference was the "pageproxystate" attribute: "valid" pre-restore and "invalid" post-restore. That attribute is set in UrlbarInput.setPageProxyState(). The relevant caller for us is UrlbarInput.setURI().
The function checks if the browser has a "user typed value", and if so, only sets "pageproxystate" to "valid" if the URL is for an empty or initial page. In the final call to setURI (it's called multiple times for a single load/restore), when SHIP is enabled,
about:robots and when SHIP is disabled, it's
null (about:robots is not an empty/initial page, so "pageproxystate" is set to "invalid" for SHIP, which results in us hiding the "site information" icon).
So now I tried figuring out why we're only setting userTypedValue for SHIP. It turns out we also set it for non-SHIP, but there are some ordering differences that affect when that value is cleared.
For SHIP restores:
For non-SHIP restores:
- We start the restore and set the current URI in ContentRestore.restoreHistory().
- We get that same onLocationChange event in tabbrowser, but we don't clear the userTypedValue yet. I'm still a little confused about why, but the difference is that
didStartLoadSinceLastUserTyping() is false for non-SHIP. It's only flipped after the reloadCurrentEntry() call in ContentRestore. FWIW, I don't think this is actually relevant to the bug, since we clear the typed value later anyways.
- ContentSessionStore sends up the "restoreHistoryComplete" message and SessionStore sets userTypedValue to "about:restore"
- It is at this point that ContentRestore calls reloadCurrentEntry().
- This triggers an onLocationChange, and the tabbrowser clears its userTypedValue. We eventually call setURI and set pageproxystate.
So I guess the problem here is that we're relying on some message ordering that doesn't actually hold for parent process document restores.