Edge’s restart-free update demo is not the setting available today

Microsoft has demonstrated an Edge prototype that can move the browser, its supporting processes and open tabs to a new version while work continues. The October 15 engineering post is explicit about its status: the approach is early research, not production code and not part of Chromium today.

The setting users can enable now does something different. “Restart to update on idle,” previously called Instant Updates, waits for inactivity and then relaunches Edge. Confusing those two mechanisms risks creating exactly the problem the research is trying to solve: someone assumes an unfinished form will remain untouched when a real restart occurs.

Restoring a tab does not restore every state

Microsoft’s support instructions describe an idle period of 15 minutes followed by a five-minute countdown, provided no active wake locks prevent the process. The browser then applies the pending update and restores tabs.

An open tab is only the visible container for a web application’s state. Its address can be reopened even when unsaved text or an incomplete operation cannot be reconstructed. Some applications save continuously; others do not. Microsoft specifically warns that unsaved documents and forms can lose content.

This does not make automatic updating a bad idea. It makes the condition “idle” worth understanding. A person can step away from a computer while an important unfinished task remains on it. Saving before leaving is still useful even when the update has been moved out of active working time.

The hard part is moving the running system

A browser is a collection of cooperating processes, not one static window. Updating it while preserving the work means coordinating a change across that system. The prototype’s ambition is to remove the moment when a security fix waits behind a user’s reluctance to interrupt a task.

The security consequence is the patch gap: the interval between a fix becoming available and the protected version actually running. Downloading an update is not necessarily the end of that interval. If old code remains active until a restart, the installation has not yet gained the full benefit of the new release.

Our report on managed Firefox deployments approaches the same operational concern from a different browser ecosystem. An organization needs to know what is running on its devices, not merely what update package has reached them.

Administrators have a separate visibility problem

The Edge management dashboard documentation describes version monitoring and security alerts for managed Windows devices. Alerts can be filtered by severity, while the dashboard helps identify affected installations and available actions.

That visibility is distinct from applying the update itself. A well-labeled alert can help prioritize work, but the administrator still needs to determine whether the running browser has moved to the required version. Likewise, a count of devices is useful only within the reporting scope and freshness of the monitoring data.

The research points toward a desirable outcome: a security update that no longer competes with keeping a task intact. Until that mechanism reaches production, the practical improvement is more modest and still worthwhile—make the restart predictable, save the work, and verify that the new version is actually running.