Web delivery and interaction acceptance workshop / 6 MIN READ
Accept a service-worker update with older tabs still open
A page-and-controller transition record showing the versions involved before, during and after an approved update.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
A release can be ready on the server without being the version that an already-open page uses. Accept the transition between page and controller versions, including the work that remains open during the change.
What you will leave with: A page-and-controller transition record showing the versions involved before, during and after an approved update.
Use this when
- A content application behaves differently in an old tab and a fresh visit.
- An update proposal would activate while readers still have the previous page open.
Not campaign expiry, ordinary HTTP revalidation, a cache-clearing instruction or permission to force activation or delete stored data.
Separate readiness from control
Google’s web.dev service-worker lifecycle guide, checked 7 November 2026, explains that an installed update can wait while the older worker still controls clients. Skipping that wait can place a new worker over pages loaded earlier. This is a compatibility question, not proof that an installation message means every open page has changed.
Choose an invented content application with an observable version label and one harmless unfinished task, such as an unsent comparison selection. Identify the page version, its controller and the assets involved with the implementation owner. Do not assume that all three share a version merely because the deployment has one release number. Write the expected reader experience before discussing an update mechanism.
Retain the old reader context
Ask for an approved fixture that keeps an older page open while the proposed release becomes available. Include another tab if multiple-tab use is supported. Record the visible document, the supplied controller evidence and the retained task state. Avoid development shortcuts that automatically refresh everything, because those can remove the condition ordinary readers will encounter.
Observe the normal transition path before reviewing any early-activation proposal. Note which reader action, if any, is expected to move the application forward and what happens if the person postpones it. A warning that an update exists is not evidence that the application has moved to it. Keep the observed sequence understandable to an editorial release owner while retaining enough technical detail for the engineer to reproduce it.
For example, a fictional fixture has two version-A pages and a newly installed version-B worker recorded as waiting. Closing one tab does not establish the final transition. The owner’s evidence must identify what still controls the remaining page and what changes when the approved transition finally occurs.
Test compatibility rather than forcing freshness
For each proposed transition, compare the old task state with what the reader sees afterward. Can a selected item still be interpreted correctly? Does a link created by the earlier page lead to the intended content? Are newly requested assets consistent with the document that uses them? These are acceptance questions for the supplied fixture, not universal predictions about every application.
Have the implementation owner explain which combinations are supported and how unsupported ones are prevented or handled. Do not demand immediate activation merely to make a release dashboard look current. An apparently faster transition can be a worse choice if it interrupts legitimate work or leaves the page operating under incompatible assumptions. Keep restoration of unfinished work, content version and technical cleanup as separate decisions with named owners.
Retain a release-specific transition contract
Capture the accepted sequence as a short record: starting versions, open contexts, update availability, transition trigger, resulting versions and reader outcome. Include an older supported starting version where the product permits readers to return after several releases. A demonstration that upgrades only from yesterday’s build may not cover the actual audience’s return path.
Do not delete unrelated caches or stored information as part of the acceptance plan. The qualified owner must scope any cleanup and recovery behavior separately. Finish with the combinations that passed and the situations that remain held. Reuse the record when the application changes its storage assumptions, update presentation or asset relationships. Success means that the supported reader transition is coherent, not that every tab was made fresh by any available means.
Make the reasoning concrete.
A fictional public catalog keeps a comparison page open while its application updates. A supplied demonstration shows the new release notice, but the team has not checked what happens to the unsent comparison when the reader accepts it.
Approve the notice
Opening: Treat the visible update notice as proof that the release path works.
Hypothesis: The deployment seems ready.
Risk: The reader’s existing page and unfinished task remain untested.
Accept the transition
Opening: Retain the older page, observe the approved transition and compare the resulting task.
Hypothesis: The team can judge version compatibility and reader continuity together.
Risk: Some starting versions may need an explicit unsupported disposition.
The catalog holds acceptance until the actual supported transition preserves or honestly resolves the invented unfinished task. It performs no production activation or cleanup.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Start
Which page and controller versions are present?
Contexts
Which tabs and unfinished tasks remain open?
Trigger
What observed event moves the application forward?
Compatibility
Which resulting combinations are supported?
Outcome
What happens to the reader’s existing work?
Watch for the wrong conclusion.
- Using a fresh visit to stand in for an older open page.
- Equating an update notice with completed transition.
- Forcing freshness without testing the reader’s retained work.
Your next action
Request one owner-supplied old-page transition demonstration and record versions separately from the reader’s visible outcome.
Sources & scope
Acceptance workflows and fictional examples are editorial analysis. Technical statements and their applications remain source-derived even when embedded in original scenarios. Results apply only to the tested environment. No real clipboard access, sharing, permission changes or production operations are performed.
- web.dev: The service worker lifecycle →Primary technical documentation · Supports: Supports installed/waiting/control distinctions and early-activation risk; other acceptance decisions are application-specific.