Text should remain when a user returns from a reference tab. Yet preservation during a switch, restoration after restart and a draft retained by the service are different capabilities. Checking those differences made me define the promise of preserving work more precisely.

A restored destination is not a restored manuscript

A tab ID and destination can return after restart while its unsent manuscript is empty. A new editor without service storage may create another blank document at the same address. Comparing tab inventories cannot establish restored content.

Actual values, local recovery material and service-side drafts therefore need separate checks. A switch preserving input supports that narrow behavior. Reopening the app and reading the same manuscript requires another test. Restored surfaces and restored content cannot share one undifferentiated success.

Local collection uses eligible fields and change records

The fixed draft operation handles ordinary text inputs, textareas and selected editable regions while excluding authentication forms, sensitive identifiers and unavailable fields. It tracks edited values and retains clearing as an empty value.

This is not serialization of every service-specific document model. Field keys include tag, ID, labels, type and structural path clues. A changed structure may no longer resolve to the same field. Retained text cannot establish complete preservation of images, formatting and media order.

Do not force a recovery copy over different content

Ordinary restoration matches the full frame destination and field identity and avoids values already edited by the user. Different current content is preserved. Applied markers also prevent repeatedly reinserting the same recovery material.

Duplicate-destination frames are ambiguous and avoid automatic recovery. A recognized blog's plain-text snapshot has a read-only path rather than rewriting its proxy DOM. These restrictions prevent recovery convenience from corrupting a service document model or overwriting another manuscript.

Elapsed collection time does not prove fresh capture

Capture waits for an existing operation and can start a fresh one when required. A per-tab deadline can retain an older recovery copy when new data is unavailable. Preserving the old copy must not be reported as capturing the latest keystrokes.

Dormant, loading, destroyed and private-profile conditions also constrain collection. Final capture before normal shutdown differs from retaining the last input before forced power loss. Service drafts remain relevant. Time, captured content and actual server records together establish the recovery scope.

Retain the cafe recovery failure too

The historical version-0.1.82 cafe test verified values at input time, but reopening cleared the new manuscript and the local recovery copy did not contain it. A later success restoring another blog document cannot retrospectively complete that failed case.

I compared the historical record with current collection and restoration code. Recovery in an owned ordinary-HTML fixture differs from a particular live editor. I did not close a user's manuscript for another experiment or infer that the old failure necessarily remains on every editor. Broader conclusions need follow-up evidence on the relevant path.

Make preservation promises at the actual material level

Everything is saved is easy to say. Real preservation identifies which text and media were retained, where and how they were read back. Local copies and service drafts can complement each other without becoming identical evidence.

I retain separate checks for convenient tab movement and manuscript recovery. Reexecuting a program also differs from restoring a document; recovery must not imply automatic publication or resubmission. Explicit boundaries let a user understand what continuity is supported and which result still needs inspection.