I believe we don't auto-restore any tabs (pinned or not) after a crash because if they were linked to the crash cause, it would make the browser unrecoverable.

So I think this is WAI.

It sounds like "Note: closing the browser ignoring the "restore tabs" and re-opening it, restores the pinned tabs" contradicts your earlier "unless you click "restore tabs" the pinned tabs are lost forever".  Can you clarify?

After a crash, if user clicks "restore tabs" then the tabs including the pinned ones are restored. This persists through a restart i.e. closing browser after this and reopening will again correctly reopen pinned tabs.

If user does not click restore tabs and instead just closes the browser without acknowledging the dialog or navigating anywhere, then reopening the browser will restore pinned tabs.

However, if the user ignores the "restore tabs" dialog and starts navigating to pages, surfing the web, then closes the browser, then the pinned tabs are lost forever. On a second restart of the browser they are also not there.

It is this third behavior that I find counter-intuitive. Sorry I wasn't clearer in my original bug report.

OK.  I don't think we can safely auto-restore the pinned tabs after a crash, which would be the easiest way to avoid people getting into this scenario.  I agree with comment 0 that it surprises me that closing the browser immediately (ignoring the dialog) and then reopening restores the pinned tabs.  But I'm not sure that should be removed.

I don't really think that, if the user does navigate and effectively "create session state", we should restore a previous session's pinned tabs on a subsequent restart.  Then we're basically mixing state from two different sessions.  Or in other words, given that we aren't restoring pinned tabs after a crash, the other behavior you describe seems correct.

Maybe there's a way to work around all this, though.  Perhaps after a crash, we should restore all the state, but not actually load any tabs (basically, the tabs are effectively in "offline" mode), and the user can either reload/navigate/close them individually, or hit something like the existing restore button to cause them all to go ahead and load.  It seems like provides the best amount of control and dataloss prevention, without actually reloading something that might retrigger the crash bug.  Then I think we bypass all this confusion.

WDYT?  +CC sky, who still owns sessions AFAIK, for thoughts as well.

Agree with your assessment Peter.