Firefox 159 brings two useful Linux fixes: tabs should no longer detach into a new window simply when clicked under Wayland, and excessive memory use when displaying map or place results on Linux with AMD graphics has been addressed. If either symptom affects your workstation, this is a practical reason to update—not a promise that every graphics or memory problem is solved.
Mozilla released Firefox 159 to the Release channel on 27 October 2026. This guide, checked on 28 October, explains which fixes matter, how to update the installation you actually use and what to verify afterward. LinuxPanda has not benchmarked this release.
Key takeaways
- The AMD fix concerns excessive memory while viewing map or place results, including on sites such as ChatGPT.
- The Wayland fix targets accidental tab detachment on a click, not every window-management issue.
- Firefox 159 also contains security fixes. Keep your supported release or ESR channel patched.
- A distribution-packaged browser and a Mozilla-downloaded installation use different update paths.
- Check the version in the running browser after restarting; a terminal command can identify a different installation.
What Firefox 159 fixes on Linux
Mozilla’s release notes identify the AMD memory-growth and Wayland tab-detachment fixes. Phoronix’s independent Linux coverage also highlights both changes.
| Symptom | Relevant fix | Do not infer |
|---|---|---|
| Memory rises excessively while displaying map/place results on an AMD Linux system | Firefox 159 addresses that scenario | A universal RAM reduction or a measured percentage improvement |
| A tab unexpectedly becomes a separate window when clicked under Wayland | Accidental detachment is fixed | That intentional tab dragging is removed, or every compositor bug is fixed |
Other fixes include memory growth with a minimized Zoom web-app window and some sites failing to fall back from HTTP/3 to HTTP/2. Mozilla also lists interface and developer changes. These are useful context, but the Linux graphics and tab fixes are the main reason for this guide.
Who should update?
Prioritize the update if you can reproduce either Linux symptom. For an unaffected workstation, use your normal supported security-update process rather than changing browsers or distribution channels just for a feature headline.
For administrators, separate two decisions: which supported browser channel your organization uses, and whether that channel is current. A managed ESR installation should follow its ESR advisory and deployment policy; a smaller major version number alone does not establish that it lacks a particular security patch.
The release is not an Ubuntu-only fix. The relevant environment is the running Firefox build, graphics stack and affected behavior. Our Ubuntu 26.10 upgrade guide covers the separate operating-system decision; a browser update does not require an OS-release upgrade.
What about the Firefox 159 security fixes?
Mozilla advisory MFSA 2026-118, announced on 27 October, rates the release’s security impact High and lists multiple individually tracked flaws. Examples include a same-origin policy bypass, CVE-2026-117860, and a sandbox escape, CVE-2026-117861, both in the DOM Navigation component.
These are separate bugs, not a newly named combined exploit. The advisory’s fixed product is Firefox 159; follow the corresponding vendor notice for ESR or distribution backports. We found no confirmed in-the-wild attack claim in that advisory as checked on 28 October. This does not prove that attacks are impossible or absent.
The short public bug entries do not establish the authentication, interaction or chaining prerequisites for every issue. Do not present them as a universal no-click root-compromise chain. A sandbox escape concerns a browser security boundary; any ultimate host impact depends on the exploit path and privileges. Updating is preferable to guessing which individual bug might be reachable.
This security release should not be confused with the earlier eMudhra certificate-trust incident. Use each advisory for its own risk and remediation.
How to update the right Firefox installation
Mozilla’s update instructions distinguish its downloaded build from a Linux distribution’s packaged version. For distribution packages, wait for the supplier’s updated package and use that package manager. Do not assume Mozilla’s internal updater manages a distribution-owned installation.
For a manually installed Mozilla build, open the menu, choose Help → About Firefox and follow the update/restart prompt. Mozilla says this normally checks for an update and downloads it when available. Availability can differ by packaging and rollout; this article does not claim that every Linux repository already supplies 159.
If you installed through a separate application-distribution system, check that installation’s update source. Avoid mixing package types merely to make one version number change: it can leave two browsers, profiles or desktop launchers to troubleshoot.
A practical verification checklist
Use the following as a suggested retest procedure, not a benchmark we have performed:
- Confirm the running version. Open About Firefox after the update and restart. Do not rely only on a shell’s
firefox --versionwhen several installations exist. - Record the environment. Open
about:support. Note the version, application binary, update channel where shown, and graphics information. Mozilla documents these troubleshooting fields. - Retest the original symptom. Try the same tab-click behavior or map/place page that previously triggered the problem. Keep the workload comparable; changed pages and extensions can affect observations.
- Check for regression. Confirm normal browsing, downloads and work-critical sites still behave correctly. If the issue persists, collect the exact build and reproduction steps before changing graphics preferences.
Firefox’s troubleshooting page also links to about:memory and its process manager. They can help describe which workload grows, but one memory reading is not proof of a leak or a fixed percentage improvement. Review diagnostic reports for private information before sharing them publicly.
Limitations and our assessment
Our assessment is that Firefox 159 is a worthwhile targeted update for affected Linux workstations. The strongest value is the match between a specific reported symptom and a vendor-confirmed fix—not a list of unrelated features.
We would not disable Wayland or hardware acceleration preemptively on an otherwise working machine. First install the supported update, restart and retest. If the same issue remains, investigate the exact driver, extensions and profile separately rather than assuming this release addresses every cause.
No measured RAM savings, performance uplift or universal compatibility guarantee is claimed here. Release notes establish the intended fixes; your deployment check establishes whether the correct build is running and whether your own workload improved.
Frequently asked questions
Does Firefox 159 fix all AMD memory problems?
No. The documented Linux fix concerns excessive memory use when viewing map or place results. Other workloads may have different causes.
Must I stop using Wayland?
Not because of this announcement. The update addresses accidental tab detachment under Wayland; test the fixed build before considering workarounds.
Why does my package manager still offer an older version?
Distribution packaging and rollout schedules differ. Check your supplier’s package and security advisory rather than replacing repositories or assuming a lower version is unpatched.
Is checking the downloaded package enough?
No. Restart Firefox and check the version in the browser you actually launch.
Comments