Seems sensible. Only 2.6% of users (with telemetry enabled) are using 32-bit Windows while 6.4% are using 32-bit Firefox on 64-bit Windows[0]. 32-bit Linux might see more use however isn't included in the stats, only 5.3% of users are running Linux[1] and I doubt many enable telemetry.

Maybe they could also drop support for older x86_64 CPU's, releasing more optimised builds. Most Linux distributions are increasing their baseline to x84-64-v2 or higher, most Firefox users (>90%)[0] seem to meet at least x84-64-v2 requirements.

[0]: https://firefoxgraphics.github.io/telemetry/#view=system

[1]: https://firefoxgraphics.github.io/telemetry/#view=general

The last release to support 32-bit x86 hardware for popular distros was:

  Distro       | Release | Support | Extended Support
  -------------|---------|---------|------------------
  SLES 11      | 2009-03 | 2019-03 | 2022-03 | 2028-03
  RHEL 6       | 2010-11 | 2019-08 | 2024-06 | 2029-05
  Arch         | 2017-11 | *Ongoing releases via unofficial community project
  Ubuntu 18.04 | 2018-04 | 2023-05 | 2028-04 | 2030-04
  Fedora 31    | 2019-10 | 2020-11 | N/A
  Slackware 15 | 2022-02 | Ongoing, this is the most recent release
  Debian 12    | 2023-06 | 2026-06 | 2028-06
  Gentoo       | Ongoing

Seems reasonable by Mozilla, to me, given precedents like the new Debian release not doing 32-bit release builds.

And doing security updates on ESR for a year is decent. (Though people using non-ESR stream builds of Firefox will much sooner have to downgrade to ESR, or be running with known vulnerabilities.)

If it turns out there's a significant number of people who really want Firefox on 32-bit x86, would it be viable for non-Mozilla volunteers to fork the current ESR or main stream, do bugfixes, backport security fixes, and distribute that unofficial or rebranded build?

What about volunteers trying to keep the main stream development backported? Or is that likely to become prohibitively hard at some point? (And if likely to become too hard, is it better to use that as a baseline going forward with maintenance, or to use the ESR as that baseline?)

>[Updated on 2025-09-09 to clarify the affected builds are 32-bit x86]

That's nice... When this was originally posted on 09-05 it just mentioned "32-bit support", so I'd been worried this would be the end of me using FF on a Microsoft Surface RT (armv7, running Linux).

Does this mean they are deleting a bunch of code, or just that people will have to compile it manually? I'd imagine there is a lot of 32-bit specific code, but how much of that is 32-bit-Linux specific code?

I'm honestly surprised just about anything supports 32-bit these days.

It's fine to keep hosting the older versions for download, and pointing users to it if they need it. But other than that, I see 0 reason to be putting in literally any effort at all to support 32-bit. It's ancient and people moved on like what, well over a decade and a half ago?

If I were in charge I'd have dropped active development for it probably 10 years ago.

32 bit Firefox doesn't work anyway. I had an old 32 bit Firefox and didn't change it when I switched to 64 bit installation (I didn't realize).

It crashed NON-STOP. And it would not remember my profile when I shut down, which made the crashes even worse, since I lost anything I was working on.

I finally figured out the problem, switched to 64 bit and it was like magic: Firefox actually worked again.

What is the memory usage difference like?

OpenBSD I386 user there, atom n270. Anyone who says it's useless... Slashem, cdda:bn, mednafen, Bitlbee, catgirl, maxima+gnuplot, ecl with common lisp, offpunk, mutt, aria2c, mbsync, nchat, MPV+yt-dip+streamlink, tut, dillo, mupdf, telescope plus gemini://gemini.dev and gopher://magical.fish ... work uber fast. And luakit does okish with a single tab.