2052953 - SessionStartup.sessionType memoizes NO_SESSION when queried before the session file is read

Status: NEW

(Core :: Session Restore, defect)

Description

[Giulia Cardieri (:giulia)]

While working on opening Smart Window by default (bug 2039365), I hit a session-restore regression: with Smart Window as the default, "Restore previous session" was disabled and the previously saved session was discarded.

I traced it to canOpenAsSmartWindow() in BrowserContentHandler calling SessionStartup.willRestore() very early during startup, before the session file has been read.

Root cause: willRestore() reads the SessionStartup.sessionType getter, which memoizes its result. When it's called before SessionStartup is initialized (session file not read yet), it falls into the NO_SESSION branch and caches that value:
link to line 427 from SessionStartup in search fox

Because the result is memoized, every later read of sessionType returns the stale NO_SESSION, so SessionStartup discards the session it was about to restore, even though there was a valid session on disk.

This isn't specific to Smart Window, that patch just happened to be the first caller to query sessionType/willRestore() this early. Any caller that touches them before _initialized would poison the cache the same way.

Expected: an early query should return a temporary value without caching it, and sessionType should be recomputed once the session file has been read / SessionStartup is initialized so a valid session is not discarded.

Note: bug 2039365 already stopped calling willRestore() on the startup path in BrowserContentHandler to avoid triggering this. This bug tracks improving SessionStartup so an early query can't poison the cache in the first place.