Firefox ESR 140 Gets Its Last Update This Month, and Your Support Floor Jumps Thirteen Versions

Firefox ESR 140 receives its last point release, 140.17, alongside Firefox 157 on September 29, 2026. After that the branch is done, and the institutions that pin Extended Support Release move to ESR 153.

If you build for nonprofits, higher education, government or libraries, ESR is your real Firefox support floor, whatever your browserslist config says. That floor is about to move forward thirteen versions in one step, which is the largest single day change to a Firefox support matrix in years. It cuts both ways, and the breaking half is getting no attention at all.

We covered the three engines you actually have to test in September. This is the other half of that question: not which engines, but which version of one of them you are allowed to assume.

What ends, and the date Mozilla has not published

The confirmed facts first.

Firefox ESR 140’s final point release is 140.17, shipping with Firefox 157 on September 29, 2026. Mozilla’s release calendar lists 157 as the last train carrying a 140.x build. Firefox 158, on October 13, lists only ESR 153.5 and ESR 115.43.0.

ESR 153 shipped on July 21, 2026 and is the successor. Mozilla’s ESR release cycle policy promises "an overlap of at least 12 weeks between the release of a new ESR version and the end-of-life of the previous ESR version." Twelve weeks from July 21 is October 13, and the previous transition landed on exactly that arithmetic: ESR 140 shipped June 24, 2025, and the Firefox 143 enterprise notes on September 16, 2025, precisely 84 days later, announced that ESR 128 was out of support.

What Mozilla has not published is an ESR 140 end of life date. We checked the 140.16 release notes, the ESR 153.0 notes, the Firefox for Enterprise 153 notes, the support article on the ESR cycle and the release calendar. None of them names a date. The closest is a vague line in the enterprise notes: "Firefox 140 ESR will continue to receive security updates during the ESR transition period."

So October 13 is a derivation, not a quotation. It follows from Mozilla’s own twelve week policy and matches the previous cycle to the day, and we expect the confirming sentence to appear in the Firefox 158 enterprise release notes on that date. Plan against it, but do not quote it as a Mozilla statement, because it is not one yet.

Firefox is on a two-week release train now

Before anything else, a change that has gone almost unnoticed outside Mozilla’s own channels and that breaks a planning assumption most agencies still hold.

Firefox moved from four-week to two-week major releases starting with Firefox 155 on September 1, 2026. The run since then is 153 on July 21, 154 on August 18, 155 on September 1, 156 on September 15, 157 on September 29, 158 on October 13.

If your cross-browser testing cadence, your regression schedule or your client-facing support statement was built around a monthly Firefox major, it is now running at half the resolution of the thing it is watching. This does not change what ESR does, since ESR still moves once a year. It changes how fast the version your non-institutional visitors are running moves away from it.

Thirteen versions land at once

Everything Mozilla shipped in Firefox 141 through 153 becomes available in one step. For anyone whose support floor has been pinned at 140 for fifteen months, this is the interesting part. The items below are the ones that change what you can actually ship, taken from Mozilla’s per-version release notes.

Things that were Firefox-blocked and now are not:

• View Transitions for same-document and SPA navigation landed in 144, with the full CSS surface. Firefox was the last engine holding this back. View transition types followed in 147. Cross-document view transitions are still not shipped, so check which half you need.
• CSS anchor positioning became enabled by default in 147, with position-try-order in 148. Tooltips, popovers and dropdowns positioned without a JavaScript library.
• The @scope at-rule in 146. Real style encapsulation for component CSS, which matters for anyone maintaining a Drupal or WordPress component library where theme styles leak.
• The Navigation API in 147.
• field-sizing: content in 152. Auto-growing textareas with no JavaScript.
• command and commandfor on <button> in 144. Declarative invokers.
• moveBefore() in 144, which moves DOM nodes while preserving their state, so an iframe keeps loading and focus is retained. Relevant to anyone using HTMX or Turbo-style morphing.

On the security side, the HTML Sanitizer API and Trusted Types both shipped in 148. For CMS work, where the standing problem is rendering content somebody else wrote, browser-native XSS defense is the single most useful thing in this list.

Also in that column: Integrity-Policy and Integrity-Policy-Report-Only headers for enforcing subresource integrity on scripts in 145, with violation reporting in 149, and Clear-Site-Data: "cache" clearing the bfcache in 141, which closes a real post-signout exposure gap.

In JavaScript, explicit resource management with using and await using arrived in 141, CSS module scripts in 147, and service workers loadable as ES modules in 147.

Platform and internationalization additions round it out. WebGPU reached Windows in 141 and all macOS versions on Apple Silicon in 147. The URL Pattern API, the Prioritized Task Scheduling API and Selection.getComposedRanges() for shadow DOM all landed in 142. Brotli arrived in CompressionStream and DecompressionStream in 147. PerformanceEventTiming.interactionId in 144 is what you need to measure Interaction to Next Paint in Firefox at all.

For multilingual public sector work, Firefox 153 completed the Intl.Locale information getters: getCalendars(), getTimeZones(), getWeekInfo(), getTextInfo() and the rest. If you have been shipping a hand-maintained table of locale metadata because Firefox could not answer these questions, ESR 153 can.

One caution on all of the above. ESR point releases carry only high-risk and high-impact security fixes. Mozilla’s own words: maintenance "is limited to high-risk/high-impact security vulnerabilities." Nothing in this feature list gets backported to 140 along the way. It arrives when the branch changes, and only then.

The accessibility unlocks are the ones to act on first

Two of these deserve to be pulled out of the list, because the audience for Firefox ESR 140 is disproportionately made up of organizations with an accessibility obligation.

contrast-color() shipped in 146. It resolves to a foreground color guaranteed to meet a minimum contrast threshold against a given background. For anyone maintaining a design system that has to hold WCAG 2.1 AA across themeable brand colors, that is a genuine reduction in hand-maintained color pairs.

ariaNotify() on Document and Element shipped in 150. It announces a message to a screen reader without the live region choreography that live regions require, which is the part teams get wrong most often in our experience: a visually hidden div, the wrong aria-live value, the announcement firing twice or not at all.

Neither is usable in a project pinned to ESR 140. Both are usable in a project pinned to ESR 153. If you are scoping an accessibility remediation for an institutional client with a 2027 delivery date, the support floor you scope against should be 153.

What breaks on the institution’s side

This half is getting no coverage, and it is the half that generates a support ticket.

Removals between 140 and 153 that can break working code:

Two behavior changes worth testing for specifically. Cross-origin iframe top-level navigation now requires sticky activation, as of 144, which can break embedded third-party widgets and older single sign-on or payment flows. And initial about:blank now loads synchronously as of 148, with load firing synchronously, which can change timing in iframe injection patterns.

We found no removed or deprecated enterprise policies across 141 to 153, and no certificate or TLS changes documented in that delta. Certificate Transparency enforcement on desktop landed in Firefox 135, before ESR 140, so it is already present in both branches and is not part of this jump.

XSLT now has a kill switch

This one is small today and is the item most worth flagging to a library or a government client.

Firefox 151 added an enterprise policy called XSLTEnabled, described as enabling or disabling "support for the XSLTProcessor JavaScript API." XSLT still works in ESR 153. Nothing is removed. But the arrival of a policy-level off switch is a signal, and it arrives alongside a cross-browser move to deprecate XSLT that includes a parallel intent-to-remove on the Chrome side.

The exposure here is concentrated in exactly the places our readers work: library catalogs, MARC and MODS pipelines, OAI-PMH front ends, and government XML-to-HTML rendering. Those are systems that were built once, work, and have nobody assigned to them.

No removal date is published and we are not going to invent one. The action is an inventory, not a migration: find out whether anything you maintain depends on browser-side XSLT, and write it down somewhere you will find it again.

The AI policies need setting before rollout, not after

ESR 153 ships user-facing AI features that ESR 140 did not have, including on-device tab organization, along with a built-in VPN.

Three new enterprise policies exist because of this: AIControls, GenerativeAI and VisualSearchEnabled. A fourth, IPProtectionAvailable, covers the VPN. GenerativeAI was backported to ESR 140.4.0 for the chatbot option only, so a fleet on 140 has partial control today and a fleet on 153 has more surface to control.

Any institution with a written AI use policy, which now describes most universities and a growing number of government offices, needs these set in the policy file before the upgrade reaches desktops, not after somebody notices a new sidebar. That is a three-line change made at the wrong time turning into a governance conversation.

Other policy changes in this range worth a read before rollout: ExtensionSettings now force-updates force-installed extensions regardless of the updates_disabled setting as of 152, and adds runtime_allowed_hosts and runtime_blocked_hosts in 153. The Containers policy has a new color palette with automatic name migration, turquoise becoming cyan and toolbar becoming gray, which will quietly rewrite any scripted container configuration. And DefaultSerialGuardSetting disables Web Serial by default wherever enterprise policies apply.

What to do

For the agency, this month: move your Firefox support floor to 153 in your browserslist and in whatever you tell clients you support. The features above are not speculative; they are shipping in the branch institutions are being upgraded onto. Scoping a 2027 project against 140 is scoping against a browser that will have been dead for a year.

For the institution, before October 13: audit in-house extensions first. The 152 removal of dynamic code execution and the 153 file access permission change are the two items most likely to break something that currently works, and both affect software an institution wrote for itself, which means there is no vendor to chase.

Test the embedded third-party things. Single sign-on flows, payment widgets and anything in a cross-origin iframe, because of the 144 activation requirement.

Set the AI and VPN policies before the upgrade, not after.

Verify the floor rather than assuming it. An institution that told you two years ago that it standardizes on ESR may since have moved half its fleet to managed Chrome, or may be running ESR 115 on a subset of older hardware that cannot take 140 or 153 at all. The question worth asking a client’s IT contact is not "do you use Firefox ESR" but "which ESR, on how many machines, and who decides when it moves." The answer changes what you are allowed to ship by more than any other single input to a support matrix.

Do not stay on 140. Mozilla’s policy is plain about what happens: the release reaches end of life, no further updates are offered, and an update to the next version is offered through the application update service. Staying put means actively suppressing that update, and it means the published security advisories for each 153.x release become a public list of vulnerabilities that are unfixed in your build. Mozilla offers no extended support, paid or otherwise, and no exception process. ESR 115 is still receiving point releases, but that is a Windows 7 and older-macOS arrangement driven by operating system support, not a precedent for extending 140.

Thirteen versions is a lot to absorb at once, and the ESR model is what makes it arrive as one event rather than thirteen. The upside is that you get to use all of it the same day.

Frequently Asked Questions