Rather than asking someone with many saved tabs to close them all, I preserve the list and load documents as needed. Lazy restoration in my browser is not tab deletion. It separates what must remain remembered from what can wait before running.
A tab identity differs from its renderer
Saved tabs contain ID, address, title, profile, project, pin/group state, mute and zoom. That list can be restored before each document is read. Current source creates saved tabs as deferred and supplies their original IDs, rather than rebuilding a list with unrelated new identities.
Keeping a lightweight WebContentsView and metadata does not mean zero memory. The relevant change is avoiding simultaneous execution of every document renderer. Separating remembered state from running state reduces startup work without implying that saved tabs disappeared. Actual memory differences still require separate process measurements; metadata preservation alone does not quantify them.
Find the remembered selection before loading what is needed
Restoration creates valid profile-owned saved tabs and reapplies title, account grouping, pinning and manual zoom. A persisted task lease is not treated as a live task after restart; the page returns to human ownership and a new task must adopt it explicitly when needed.
The host then finds the remembered activeTabId for the current profile/project, or an appropriate first tab, and select calls wake. Twenty saved tabs can therefore remain in the list while loading begins with the selected document. Preserving IDs does not automatically restore execution authority from the previous process. That distinction is part of restoration, not a separate cosmetic detail.
Wake within the original session and document lifetime
Wake waits for the original profile session before restoring a URL or retained navigation entries. An explicitly attached background tab also needs real viewport dimensions for observation, instead of being read at zero size and mistaken for empty content. Reading that attachment need not redefine the person's selected working tab.
Waking a dormant document reloads it, so temporary script state and scroll position are not promised complete restoration. Retained navigation is a bounded set of URLs and titles, without replaying POST bodies. The feature does not obtain lightness by cloning login storage or deleting caches. It states which information is retained and which document state must be read again.
Test identity and selection rather than tab count alone
The existing startup test prepares twenty identical saved tabs, a particular activeTabId and composer notes. Lazy startup checks nineteen dormant entries and zero renderer PIDs, then clicks another tab and verifies its identity and manual zoom. Restart checks the last selection and saved list again.
Historical version 0.1.61/0.1.62 results retain that distinction. Here I reread version metadata, renderer counts and numeric samples and recalculated the saved figures without launching a new app. Even a matching list still makes the person find their work again if the last selection resets. A matching tab count is weaker than preservation of the actual identities and user state. Those are the properties the record makes inspectable.
The shared example inspects policy rather than restoring tabs
The synthetic package tests sleep candidacy and reading-cache lifetime. It creates no renderer and wakes no tab. Restoring the tab list and connecting its original profile session remain responsibilities of the real host. A candidate result from the small example is never reported as a completed tab close.
Another work tool can distinguish its document list from running resources too, provided it states protection for unsaved work and what reopening loses. I record a choice that preserves the traces of work while deferring execution, instead of treating fewer saved tabs as the prerequisite for a lighter start.