A Mozilla developer is prototyping a new mechanism on Windows that delivers link launch requests directly to a Firefox instance that is already running. According to the public development issue "Bug 2087194," a quick test with a local build cut the time it takes for a link launch request to reach the running Firefox from about 70 milliseconds to about 3 milliseconds. Currently, Firefox starts a separate process and relays the request to the existing browser. The new approach uses a Windows feature to skip that step. However, the measurement does not reflect the time it takes to load or display a web page. It covers only the delivery of the launch request.
Development is still at the prototype stage, and the new feature is disabled by default. The Firefox version in which it will officially ship, and the timing, have not been disclosed. Challenges also remain, such as deciding which instance should receive a request when several Firefox profiles, for example work and personal ones, are in use at the same time.
A new way to deliver links straight to a running Firefox
The improvement targets "warm launches," in which an application that is already running is reused. For example, when you click a web link in another application such as email or chat and Firefox is already running, that instance is used to open the page. Until now, Firefox has briefly started a new firefox.exe process, relayed the request to the existing instance, and then exited. The same relay is also used when Firefox is launched from the Start menu or taskbar.
What is being tested in Mozilla's development issue "Bug 2087194" is a way to eliminate this relay process by using Windows' "Accelerated App Launches." According to Microsoft's developer documentation, Accelerated App Launches lets an application register in advance a window that receives launch requests. Requests to open a URI are delivered with the Windows message WM_COPYDATA, while launches from the Start menu or taskbar use a different window message. In Mozilla's prototype, the developer reportedly confirmed that Firefox could directly receive not only web links but also launch requests from the Start menu.
Because this approach removes the need to start a new process and relay the request, the time needed to deliver a launch request to the running Firefox can be shortened. However, what improves is only the path for handing a request to an existing browser, which is different from a cold start from a state where Firefox is not running. Nor do tasks such as fetching web page data, running JavaScript, and rendering get faster by the same proportion. How much this change affects the speed users perceive would need to be measured from the click on a link to the moment the page actually appears.
From about 70 ms to 3 ms, though Edge's speedup was measured differently
Mozilla's development issue reports that delivering a link request, which took about 70 milliseconds with the old method, was completed in about 3 milliseconds with the new one. A simple calculation puts the reduction in delivery time at about 96%, but this comes from a quick test with a local build. The specifications of the PC used, the Windows build number, the number of measurements, the variance in results, and a precise definition of the starting point of the measurement are not given. The figure of about 3 milliseconds therefore cannot be treated as performance reproducible on a typical Windows environment.
Separately, Microsoft announced on October 29, 2026 that Edge had become the first browser to support Accelerated App Launches. According to Microsoft's official blog, comparing Edge with and without the acceleration feature while Edge was already running showed a 15% improvement in warm launch speed, and up to 33% in heavy multitasking scenarios. However, what Microsoft showed is the improvement rate for warm launches as a whole, which differs in scope from the request delivery time Mozilla measured.
The two companies' announcements and measurement conditions can be summarized as follows.
| Reporter / target | Published result | What was measured / conditions | Information not disclosed |
|---|---|---|---|
| Mozilla: Firefox | About 70 ms before, about 3 ms with the prototype | Quick test with a local build. Time for a link request to reach the running Firefox | Test machine, Windows build, number of measurements, variance, precise measurement starting point |
| Microsoft: Edge | Warm launch improved 15%, up to 33% in heavy multitasking | Comparison with and without the acceleration feature while Edge was already running | Absolute times, detailed test conditions |
Firefox's reduction from about 70 ms to about 3 ms is a measurement limited to request delivery. By contrast, Edge's 15% and up to 33% figures are the warm launch improvement rates Microsoft reported. Because the measurement scopes differ, these numbers cannot be compared directly to rank Firefox and Edge by speed. And even if Firefox's delivery time dropped by about 96%, the user's overall wait time would not necessarily shrink by the same proportion.
Multiple profiles and Windows-side requirements remain challenges
One issue remains before the new method can be officially adopted: deciding which Firefox instance should receive a launch request. Mozilla's development issue lists as an unresolved matter which instance should receive a request when several profiles are running at once. Firefox profiles are a mechanism for keeping browsing history, settings, extensions, and the like separate by purpose. For example, if work and personal profiles are open at the same time, the user's environment differs depending on which one opens a link clicked in an external application.
Even when the traditional relay is skipped, this routing has to be handled properly. However, what Mozilla's issue points out is a design question about how to decide the destination, not a report that the prototype actually delivered a link to the wrong profile. Whether behavior equivalent to the current one can be maintained with multiple profiles in mind will be a challenge for official adoption.
Windows also has conditions for using Accelerated App Launches. According to Microsoft's specification, launch requests using a URI scheme can be accelerated only when the application is registered as the default handler for that scheme. A URI scheme is the identifying part at the start of a URI, such as https:, and the default handler is the standard application that opens that type of URI. In other words, even if an application has registered a URI scheme for acceleration, if a different app is the default handler, that URI request is not eligible. However, this is a condition for URI-based launches, and the same condition does not necessarily apply to every launch path, such as the Start menu or taskbar.
In addition, the Accelerated App Launches API is a restricted-access feature. Mozilla's developer explains that Firefox being an unpackaged application was not a barrier, and that the unlock code already used for the taskbar pinning feature made this API available as well. On the other hand, whether Mozilla needs to contact Microsoft before using it officially is left as an open question. The test results alone do not show that this API is unconditionally open to all applications.
Maintaining the traditional launch path is also necessary. Microsoft's developer documentation recommends keeping the existing mechanism of relaying requests to an existing instance, because Accelerated App Launches does not support every Windows version or launch method. Even if Firefox adopts the new method, it will therefore still need to deliver requests through the traditional relay process in environments where the new method is unavailable. In addition to supporting the new method, a mechanism will be needed to determine when it can be used and fall back to the old method when necessary.
Official adoption undecided; perceived speedup needs further testing
At the time of checking, Mozilla's development issue was marked "ASSIGNED," indicating that work is continuing. The prototype feature is controlled by the setting widget.windows.accelerated_launch.enabled and is disabled by default. It also supports control through Mozilla's feature management system "Nimbus," but it cannot be confirmed whether the feature is being rolled out to general users. The Firefox version that will officially support it and the release timing have not been announced at this stage.
Alongside introducing Accelerated App Launches in Edge, Microsoft has said it will contribute the work back to the Chromium project and extend acceleration to opening PDF files. Mozilla's effort, by contrast, is an independent implementation for Firefox to use the Windows API directly. A Windows update alone therefore will not automatically add the same mechanism to existing Firefox. Firefox itself must complete the necessary development and testing and incorporate it into an official release.
The focus going forward will be how to decide the destination when multiple profiles are running, how to determine environments where Accelerated App Launches can be used, and how to implement the fallback to the traditional method. In addition, measuring actual operation time, from the click on a link through window display to page load, would make it possible to evaluate how much of this speedup is reflected in users' wait time. The prototype result of cutting request delivery from about 70 ms to about 3 ms is promising, but how noticeable the effect will be in everyday browsing depends on future testing.