cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

The new Firefox design lands in today. This is what you can expect

AshleyT
Employee
Employee

Firefox has evolved significantly over the past year and now, its look has evolved too. 

The design begins rolling out today, with Firefox 157, bringing a cleaner, more cohesive , and more adaptable experience. It is still the Firefox you know and trust, with the same commitment to independence, privacy, customization, and user control. 

The Mozilla Connect community has helped shape this work from the beginning by sharing feedback on the early designs, tested the experience in Nightly starting in July, filed bugs, and shared with us what worked and what didn’t.

Here’s what landed today.

A cleaner, more cohesive design

  • Softer tab shapes
  • Redrawn icons that hold up better across light and dark themes
  • Rebalanced spacing throughout the interface
  • A refreshed color palette featuring the glow of the active tab, deeper purples, and warmer light tones

The updated design brought bolder color choices to Firefox — and your feedback made clear that opinions on browser color run the full spectrum. In response, we created additional themes, accessible through add-ons and a new theme picker off Firefox Home, so you have greater control over how Firefox looks. 

More ways to make Firefox yours

Firefox is becoming more customizable, giving you more ways to shape the browser around how you browse. These options include:

  • A new theme picker in the customization panel on the Firefox Home page. Additional community themes remain available through about:addons.
  • New Firefox themes and wallpapers
  • A dedicated space to pin and organize shortcuts so sites you use all the time stay put.
  • Compact Mode for a denser browsing experience

Compact mode now officially supported!

Compact Mode is now available as its own dedicated setting. It will also switch on automatically on smaller screens, reducing the space between interface elements so more fits on the screen.

This is one of the clearest examples of how community feedback shaped Nova. Many of you told us that maintaining a denser interface was important, and we listened.

Faster performance

The refreshed experience also includes improvements to Firefox’s startup, page-loading, and scrolling speeds.

Frequently asked questions

Will my existing themes and add-ons continue to work?

Themes and add-ons should continue to work. Nova is built on the same Firefox foundation, and the extension and theming architecture has not changed.

Will my userChrome.css customizations continue to work?

Some customizations may require minor adjustments, depending on how closely they rely on element names or layout structures from the previous interface. 

But keep in mind that Mozilla does not officially support customizations made through userChrome.css. They can cause unexpected behavior or even break Firefox, and future updates may affect them as Firefox continues to evolve. If you choose to use userChrome.css, please proceed carefully.

You can learn more in Firefox advanced customization and configuration options.

Can I opt out of the update?

The new Firefox design becomes the default experience starting with Firefox 157. However, you have several ways to adjust how Firefox looks and feels, including Compact Mode, themes, wallpapers, and New Tab customization. 

Keep shaping Firefox with us

Nova may be shipping today, but the work doesn’t stop here. Many of these updates grew directly from the bugs you filed and the conversations you started while the design was being developed.

Update to Firefox 157 to try the refreshed experience, then let us know what works well and what could still be improved. Your feedback will continue to help shape what comes next.

848 REPLIES 848

KrownProductsLt
Making moves

Sound is borked in 157 for Linux Mint. Volume levels are too low on all videos. Had to install 'Sound Adjuster' plug-in and set db gain to 3x to get audio levels restored. Not an issue with Vol Control, headsets, muting, external speakers, recent Linux updates or anything else hardware related. This is only happening with Firefox 157.0.1 from the pushed update. Reviewed the audio settings in About:config but could locate an issue.

Please fix this problem.

The best solution to the ugly, less functional Nova UI (at least for the next year) is to switch from regular Firefox to Firefox ESR (Extended Support Release), which retains the classic Proton UI and is also more stable. See Navas' Tips: Firefox UI Debacle

sosasees
Familiar face

 With how Mozilla is clearly disreguarding User Feedback now, we need Helium and Ladybird to save our Web Browsing Experience.

Yeah, might be waiting a while for Ladybird... all you can do for now is download the source-code and build yourself (and then, only on macOS or Linux) to get a window with a URL bar but nothing else.

Windows will come years later, followed-by Android and iOS much-later.  So for now, you might be better-off looking into a "fork" of Firefox (e.g. Basilisk • Floorp • Librewolf • Pale Moon • Waterfox), or look into the business version which predates the new UI.  Details here:
https://tips.navas.us/2026/10/firefox-ui-debacle.html 

JNavas
Contributor

Version 153.5.0, first offered to ESR channel users on October 13, 2026
I confirm this update retains the classic Proton UI. 👍👍

noonespecial1
Making moves

change it back

leojth
Making moves

Mozilla, if you think "they will get used to it", I can tell you that I never liked or got used to the detached tab buttons, but I could tolerate it. This new design, I can not tolerate.

When new design comes, I usually try to use it for a while, but this I had to revert immediately. Active "tab" looks like a text box, not a tab. (if it actually was a text box it would be rather cool). Together with adress bar it looks like two misaligned text boxes (dark mode, horizontal tabs).

My opinion is that at least the active tab should look like a tab and not something else.

Makoto
Making moves

There seem to be many critical voices, but I personally think the new design is better than the previous one.
However, the tab design for "Container Tabs" doesn't appear to have been updated to match the new look, so I would like to see that addressed.FirefoxContainerTab.png

> "... I personally think the new design is better than the previous one"

You appear to use macOS, so obviously the new design fits in the best on that system.

It looks odd though on Windows and most Linux distros that don't try to mimic the macOS look (e.g. elementaryOS).  So glad you like, and enjoy, but they should allow others to reverse the look easily.

nordo
Making moves

This new theme/look is horrible. I can't stand how it looks. Stop forcing this garbage on us.

dftf
Collaborator

You can consider move to 'ESR' version to avoid new look for about a year from now, see:
https://tips.navas.us/2026/10/firefox-ui-debacle.html 

MrMoosticles
Making moves

If want useless bells and whistles i will use Opera. I use firefox because of its ease of use and extensive extension library. You are going down a **bleep** path with last few updates. We want simplicity, efficiency and reliability not deep umber or profiles.

sosasees
Familiar face

I very much dislike the Nova Style.
It looks great in Landmarks like the Firefox Website and About Window
but it’s super distracting in the actual Browser.

To fix the big Issues that i have with Nova, i changed advanced Firefox Settings like this:

  1. Download the Proton Theme to grey out the garish Colors that clash with most Websites.
    Unfortunately, this does not reduce how much the Corners are rounded, even though the Preview Image suggests that.
  2. Enable the Secret Setting that lets you change the Browser’s Look with CSS Styles.
    In about:config, this Setting should be toggled on (true):
    toolkit.legacyUserProfileCustomizations.stylesheets
  3. Open the Page about:support to find Profile Directory and open it.
  4. In that Profile Directory, create the Folder chrome, if it isn’t already there.
  5. In the chrome Folder, create the File userChrome.css and edit it.

My userChrome.css File looks like this:
Though yours may look different, based on your Priorities and Firefox Version.
This Stylesheet is for Firefox Version 160.

/* START Nova Rounding Adjustments */
:root {
    --border-radius-xsmall: 2px !important; /* Nova Default: 4px, Proton Default: 2px */
    --border-radius-small: 4px !important; /* Nova Default: 8px, Proton Default: 4px */
    --border-radius-medium: 6px !important; /* Nova Default: 12px, Proton Default: 8px */
    --border-radius-large: 8px !important; /* Proton Default: 16px, [Undefined in Nova] */
    --border-radius-xlarge: 10px !important; /* Nova Default: 24px, [Undefined in Proton] */

    
    --tab-border-radius: var(--border-radius-medium) !important;
    
    --button-border-radius: var(--border-radius-small) !important;
    --toolbarbutton-border-radius: var(--border-radius-small) !important;

    /*--card-border-radius: var(--border-radius-small) !important;
    --card-border-radius-compact: var(--border-radius-small) !important;
    --card-cover-image-border-radius: var(--border-radius-small) !important;

    --input-text-border-radius: var(--border-radius-small) !important;

    --menuitem-border-radius: var(--border-radius-small) !important;

    --popup-border-radius: var(--border-radius-small) !important;*/

    --panel-border-radius: var(--border-radius-large) !important;
    --panel-menuitem-border-radius: var(--border-radius-medium) !important;
    
}
.tab-group-label, .tab-group-label-hover-highlight {
    border-radius: var(--border-radius-medium) !important;
}
tabpanels, .browserContainer  {
    border-radius: 0 !important;
}
.urlbar-background, .urlbar-input-container {
    border-radius: var(--border-radius-small) !important;
}
sidebar-bookmark-row, details summary, sidebar-tab-row, input {
    border-radius: var(--border-radius-small) !important;
}
/* END Nova Rounding Adjustments */

I started with this Stylesheet and modified it with Help of Browser Toolbox to address remaining Spots which look wayy too rounded.
I especially hate the Droplet Shape of the Tab Group Headings, so this Stylesheet also turns them back into Rectangles.
I also dislike how the Web View is rounded at only the top left Corner when i enable vertical Tabs, so this Stylesheet sharpens the only rounded Corner of the Web View.


UserChrome.css only changes the Browser Chrome. It cannot touch the Browser UI inside the Web View.
To style Firefox Pages like New Tab and Settings and Firefox View, you need another Stylesheet named UserContent.css, in the same chrome Folder.

I did not setup a UserContent.css File because i find Nova’s subpar Design not so distracting on Pages that i don’t see that often when browsing
but i know that many Users can’t stand the round Edges and purple Highlights even on the Settings Page.


I did not use GenAI when making this Stylesheet.
This was a 4‑Hours‑long Project with proper Quality Control.


If Firefox Staff reads this, they may notice the Result is very similar to the actual Proton Design of Firefox up to Version 156.
A Less rounded Corners Setting should be built into Firefox, so that Step 2 and beyond don’t need to be done.
By reverting the epic Fails of Nova, these Improvements shine:

  • Tab Groups no longer change Color when opened or closed.
  • Compact Mode is now more compact.

Firefox ESR is a better solution. See Navas' Tips: Firefox UI Debacle 

I already installed Firefox ESR  but it will also adopt Nova in a Year, so i am exploring permanent Solutions to use Web Browser with a good Design.

This mainly includes userChrome.css and Firefox Forks.

> I already installed Firefox ESR but it will also adopt Nova in a Year

Maybe, maybe not—the new CEO might come to his senses in the meantime. The backlash is fierce.
I will stick with ESR as long as it does not go Nova, and only abandon Firefox if and when it does. I will not go with a Firefox fork because of security and stability issues. Edge is my 2nd choice to Firefox, now that support for Android extensions is being rolled out.

Agentvirtuel
Leader

cadwellm
Familiar face

Waterfox

  • Nova Status: Already has Nova as of their August 2026 "Supernova" update. While Nova is now native, it uniquely lets users easily choose between the Nova, Proton, and Photon interface layouts directly in its settings without using hacks.
  • Best For: Users who want modern web compatibility but need native toggle switches to stay on flat panel designs

Floorp

  • Nova Status: Hybrid. Code based on the modern Extended Support Releases (ESR), meaning it inherits upstream foundations. The developers explicity disabled Nova.
  • Offers deep built-in CSS configuration menus that allow you to strip away modern floating curves and customize panel styling entirely.
  • Best For: Power users looking for absolute control over turning off or heavy tweaking of layout elements.

Pale Moon

  • Nova Status: Never. It completely split from modern Firefox years ago to run on its own layout engine.
  • Strictly locks in a classic, traditional 2010s desktop layout.
  • Best For: Users who want a pure, old-school layout, though some modern sites may experience web standard compatibility issues

LibreWolf

  • Already on Nova: It mirrors the rapid release cycle of the core Firefox codebase.
  • Directly inherits the layout changes, though you can still use custom userChrome.css configurations to trim down the look.
  • Best For: Privacy purists who care about zero data tracking and telemetry removal rather than structural layout changes.

I posted this once already but, for some reason, it was taken down. I wonder if the mods did it? I'll keep reposting it whenever necessary.

The next thing to consider with forks: how often are they updated?

Basilisk: every two-three months (https://basilisk-browser.org/releasenotes.html , https://basilisk-browser.org/oldreleasenotes.html ) - could be unsafe to use

Floorp: every one-two weeks (https://blog.floorp.app/en/categories/release/)

Librewolf: every one-three weeks (https://librewolf.dev/librewolf/bsys6/releases)

Pale Moon: sometimes every one-two weeks, sometimes one-two months between updates
(https://www.palemoon.org/releasenotes.shtml , https://www.palemoon.org/releasenotes-archived.shtml ) - could be unsafe to use in the delays between major version bumps

Waterfox: about every two-three weeks (https://github.com/BrowserWorks/waterfox/releases)

Good info and thank you for providing it!

What matters most is the lag in releasing security updates.
The raw release cadence can reflect stability issues—more frequent updates tend to be destabilizing.

Sure, but I haven't got the time to look into "when did Firefox first address X, Y or Z issue, and how long did it take each Firefox fork to incorporate that into their own codebase"?

If you (or someone else) is interested in that, I'm sure that's the sort-of-thing an AI could easily answer, given the change logs, version-history and CVE databases are all publicly-accessible, so should be in their data-sets.

Though, with-respect, what is your current recommendation, as so far:

- The about:config change isn't good-enough, as it only lasts until late November;
- The ESR is (was?) your current recommendation, until late September '27...
- ...though in recent-posts you've suggested people move to Microsoft Edge...
... but you also acknowledge Edge updates are delayed versus Google Chrome.

So... why not just recommend people switch from Firefox to Chrome? 🤷🏻‍♂️ I'm honestly getting fatigued trying to keep-up with where you're at.

It's getting a bit tiring sometimes posting things on this site only to keep being jumped-on by yourself to correct me.  There's no harm in suggesting "forks" to people: they should then do their own research into them.

Ouch! I feel your pain, but there is no call to take it out on me. Politely pointing out that release cadence does not ensure security or stability is fact, not jumping on you. It's never my intention to be rude. I apologize for any unintentional offense. 

On your specifics:

  1. Yes, I see no point in a change that only lasts for a month.
  2. Yes, I think ESR currently makes the most sense, not only for UI, but also for stability.
  3. No, I said I will likely stay with ESR unless and until it goes Nova.
  4. No, I said I think Edge is 2nd best to Firefox ESR for me, and listed the reasons.
  5. No, I have not said Edge security is delayed. Microsoft has actually done a good job in both security and stability.
  6. I do not recommend Chrome for a number of reasons, starting with privacy and stability.
  7. Yes, my recommendations can evolve as I gain new information, in part from you, for which I've thanked you, and thank you again.

Everyone is of course free to make their own choices, but I think they should be warned of the very real risks of forks, don't you?

Okay, could I politely suggest unless there something major you feel you need to call me out over that you don't reply further?  Seems every time the 🔔 shows a new notification alert on this site now, it's always you challenging me over something and it's becoming fatiguing. 😔

I agree the ESR is a better solution for people to move to than the about:config change, but that is a simple change they can do immediately to at-least restore their preferred look so they can continue to use their current Firefox install while they switch to ESR, or perhaps research into a fork.

I accept some forks are not updated very-often.  But then how-many people who use Windows, or macOS or even Linux have audited the code personally?  Even for Firefox itself (or most open-source apps, like LibreOffice or VLC), how-many people have checked every line of code in the latest versions then do-so for all the new or changed code between that, and each future release?  All software comes with some level of trust.

Microsoft Edge may be a great alternative; but if people are taking the time to post on a forum for Mozilla products, that usually implies they like Firefox.  And if Mozilla don't decide to allow undoing of Nova, then by the next ESR release, they'll be stuck.  So I see no issue in saying "here are some forks you could look into", especially as some have committed to avoiding Nova.  As the saying goes "you can lead a horse to water, but you cannot make it drink" -- people are expected to do their own homework.

I honestly feel there is nothing more to add on this topic now.

Short-term: about:config -> "browser.nova.enabled" -> "false"
Longer-term: switch to ESR 153.5 (https://www.firefox.com/download/all/desktop-esr/ )
Even longer-term: look into Firefox forks (e.g. Basilisk, Floorp, Librewolf, Pale Moon, Waterfox, Zen), or move to Brave, Chrome, Edge, Opera, Safari or Vivaldi.

This is an open discussion forum, and asking someone to self-censor just to avoid annoying you is not reasonable. When advice is shared publicly, responding isn't "jumping on you"—it's continuing the discussion by providing other users with the technical context to make sound choices and protect their systems.

In that context, two of your core assumptions have serious flaws:

1. Trust: Equating trust in major operating systems like Windows, macOS, and Linux with trust in independent browser forks fundamentally misstates software security. Ordinary users do not need to audit code line by line because established platforms back their software with dedicated, full-time security engineering teams and rapid zero-day patch pipelines. Downstream forks maintained by a few volunteers do not have those enterprise resources. Trusting a hobbyist fork hacking a massive codebase is not the same as trusting an upstream vendor with an accountable security apparatus.   

2. Homework: You suggest users can research forks on their own. In practice, a typical user cannot audit inter-process communication (IPC) patches, verify whether silent upstream security fixes were applied, or evaluate whether a frozen UI compromises sandbox boundaries (as you conceded earlier with "haven't got the time"). Expecting non-engineers to perform that level of security analysis is completely unrealistic, which is why pointing people toward forks without clear warnings about maintenance lag and other risks leaves them exposed.

Another fork problem is continuity. Forks frequently degrade or even get abandoned entirely when key volunteers move on. As in finance, "past performance is no guarantee of future results."

you're crowding the conversation with your endless posts, lets focus on what's important here... this update is awful. 

Again: "This is an open discussion forum, and asking someone to self-censor just to avoid annoying you is not reasonable." When you have an issue with someone, you should use direct Message.

Your blanket dismissal that "forks are unreliable" completely ignores how open-source software engineering actually works. Since you claim to manage enterprise organizations, then you know that security is a matrix of trade-offs, not a single metric.
 
Because modern Waterfox is built directly on Firefox ESR (which you have touted as a replacement for Firefox) it inherits upstream security patches out of the box. Waterfox isn't a bunch of hobbyists rewriting Firefox's security architecture from scratch. They are pulling directly from Mozilla's own corporate-hardened ESR source tree.
 
Standard Firefox is increasingly bloated with telemetry, third-party integrations like Pocket, proprietary DRM hooks, and experimental AI sidebars. Every single one of these additions expands the browser's attack surface.
 
Waterfox strips all of that out. By removing complex, experimental features (like Normandy or Nimbus remote profiling), Waterfox removes entire categories of potential security exploits before they can even be discovered.
 
Even major browsers experience massive patch gaps. Chrome, Edge, and Safari routinely leave zero-day vulnerabilities unpatched for days while they test stability across their sprawling feature sets.
 
Look at Waterfox's current GitHub commit logs and release history. The developer consistently pushes out minor "dot releases" (like the 6.6.x chain) within days of Mozilla publishing a Foundation Security Advisory.
 
It trades immediate 48-hour access to standard Firefox feature patches for a drastically reduced attack surface—stripping out telemetry, Pocket, and experimental AI features that inherently introduce risk. For users who prioritize data isolation and attack-surface reduction over a 72-hour patch window, it is entirely viable and reliable.
 
If you want to look at actual metrics rather than assumptions, the data shows that Waterfox's security response time is exceptionally tight. For example, when Mozilla dropped MFSA 2026-108 for Firefox ESR on October 13, 2026, Waterfox 6.7.6 rolled out with the exact same upstream patches on that exact same day. When MFSA 2026-22 dropped earlier this year, Waterfox patched it within 24 hours.
 
A 0-to-24 hour window is an enterprise-grade turn-around for an independent fork. Claiming a project is 'unreliable' when it mirrors corporate upstream CVE patches in under a day completely misrepresents how efficiently modern open-source rebasing works.
 
There, this user has done her homework and shared it with the world.

GitHub release timestamps only prove that someone has run fast rebases, not that the result is secure and stable. That kind of superficial "homework" creates a false sense of security. What it misses from a real software engineering perspective:

1. "Stripping out code" is not simple. It creates permanent divergence.
Removing telemetry, Pocket, Nimbus, etc, from a monolithic 20+ million line codebase requires custom patches that can affect internal APIs and IPC code, and every custom patch creates a permanent delta. When Mozilla refactors underlying code, those custom patches result in merge conflicts. Resolving those conflicts without introducing new bugs or breaking sandbox isolation is extremely difficult, and time-consuming when done properly, and that is where regressions live. The overall effect is to increase, not decrease, the risk of vulnerabilities.

2. Fast turnaround on public CVEs is not real security.
A 24-hour turnaround on an MFSA advisory just means the maintainer pulled public Mozilla commits, but tells you nothing about:
• The security-relevant hardening commits and defensive refactors Mozilla may land quietly between public CVEs.
• Whether the fork's custom delta inadvertently conflicts with an upstream fix.
• Whether stripped-down code paths introduced new logic flaws.

3. The infrastructure gap.
Enterprise-grade security is not a fast Git merge. It is continuous, automated quality and regression testing on hardware farms, and multi-party architectural review. Independent forks do not have anywhere near comparable resources, and without them you are flying blind.

4. Supply chain and institutional knowledge.
Enterprise organizations don't evaluate security solely on code deltas; they evaluate the entire chain of custody: who controls the build servers, and who audits the pipeline. What happens when volunteer maintainer(s) burn out, fall ill, or abandon the project? Waterfox has already changed ownership twice before (sold and later reacquired):

The use of a fork is a legitimate personal preference, but do not confuse rapid GitHub release tags with robust security. They are not remotely the same thing.

It’s fascinating how the argument shifted from 'forks take way too long to patch' to 'fast patching is a superficial false sense of security.' That is a textbook moving of the goalposts.
 
To clarify the software architecture: Waterfox isn't rewriting 20 million lines of a monolithic codebase or manually cutting out APIs to remove Pocket and telemetry. It utilizes Mozilla's own built-in build flags and configuration toggles—the exact same ones Mozilla provides for enterprise administrators to strip down the browser.
 
Furthermore, Waterfox doesn't need to replicate Mozilla's multi-million dollar hardware testing farms because it builds directly on top of stable Firefox ESR branches. The heavy lifting of sandbox testing and architectural review is already baked into the ESR upstream code that Waterfox inherits.
 
Bringing up historical ownership changes doesn't change the fact that the code and build pipelines are entirely public, open-source, and auditable on GitHub. For users seeking data isolation, utilizing Mozilla's own enterprise-hardened ESR core without the consumer bloat is a mathematically sound reduction of risk.
 
But hey, feel free to have the 'final word' on that, too.

Pointing out failure modes isn't moving goalposts.

  • If a fork lags behind upstream, users sit exposed to known CVEs.
  • If it rushes a rebase out the door in 24 hours without thorough code analysis and regression testing, it risks shipping broken security boundaries.

It's the classic Catch 22 of maintaining downstream code.

Your argument rests on two technical fallacies:

Fallacy #1: Waterfox is just "built-in enterprise build flags and toggles."

  • Enterprise admins don't compile browsers from source with flags. They deploy signed upstream binaries and manage runtime settings via policies.json or OS-level Group Policy (GPO).
  • Waterfox is not just a toggle switch. A quick look at their repository shows a permanent delta of custom patches across C++, Rust, and JavaScript modifying internal APIs, UI chrome, and IPC contracts.
  • If removing telemetry were truly just a matter of flipping Mozilla's enterprise switches, why download an unofficial third-party binary? You can do that natively in official Firefox ESR with a 5-line policies.json and keep official signatures intact.

Fallacy #2: Test coverage and sandboxing are "baked in" and inherited.

  • Upstream CI, fuzzing farms (ASan/TSan), and regression suites only validate Mozilla's specific shipping configuration.
  • The moment a fork rips out subsystems or modifies parent/child process messaging, it enters an untested state space.
  • Stripped code paths can leave unhandled IPC states or broken isolation assumptions that upstream test suites never exercise. You cannot inherit test coverage for code combinations Mozilla never ran.

Public code on GitHub makes a project inspectable, not audited. Run whatever browser you prefer, but don't confuse an untested custom rebase with enterprise security.

For an enterprise administrator, confusing a runtime GPO (policies.json) with a compile-time build configuration is a pretty massive oversight.
 
A policies.json file can hide a feature from a user, but it does not strip the telemetry compilation code, Pocket binaries, or Normandy/Nimbus remote-execution frameworks out of the actual compiled binary. Waterfox disables these deep architectural components at the source level using Mozilla’s own compile flags. The reason users download Waterfox instead of doing it themselves isn't a mystery—it's because normal human beings don't want to maintain a local build toolchain to compile a web browser from scratch every week.
 
Furthermore, trying to frame a UI-focused layout delta as 'destroying sandbox isolation' is pure hyperbole. Waterfox is modifying the interface chrome and disabling telemetry modules; it isn't rewriting the core Quantum rendering engine or low-level OS sandboxing wrappers.
 
You can keep writing essays to try and spin a 24-hour CVE patch turnaround as a bad thing, but the hard data remains: the browser is actively maintained, inherits the core ESR security architecture, and patches vulnerabilities instantly. Feel free to take the 'final word' for a third time, though.

P.S. Your grand statements that 'the moment a fork rips out subsystems... it enters an untested state space' and 'you cannot inherit test coverage for code combinations Mozilla never ran' aren't deep architectural insights unique to forks. That is just a basic universal law of computing.
 
It applies to literally every single piece of software on Earth—including every minor dot-release, security patch, or configuration tweak Mozilla pushes out to standard Firefox. The moment any developer changes a line of code, it enters a new state space. Trying to dress up foundational computer science truisms as scary, specialized security risks unique to Waterfox is just empty hyperbole.
 
And to address your confusion over 'official signatures' and 'unofficial binaries':
Waterfox isn't an 'unofficial binary'—it is the official, first-party release of the Waterfox project. A code signature isn't a magical stamp of safety from Mozilla; it is a cryptographic proof of file integrity. Waterfox binaries are fully signed with valid developer certificates recognized by Windows and macOS to ensure the file hasn't been tampered with.
 
Asking why someone would download Waterfox instead of compiling Firefox source code with flags themselves answers its own question: users want a ready-to-use browser without maintaining a local build environment. Your attempt to use basic code-signing mechanics as a scare tactic shows just how empty your argument has become.

You've completely mischaracterized my posts with red herrings and misstatements that reflect your obvious misunderstanding of enterprise software engineering. But your insulting tone ends the discussion. We'll just have to agree to disagree.

Thank you for the conversation. Ultimately, I'm just glad a detailed breakdown of how forks operate was laid out in the open so fellow users have the info they need to make an informed choice. Take care!

medin
Making moves

This new design looks not professional, too much round corners and round buttons, it feels like it was done by a kid loving round shapes.

maiconandsilva
Making moves

I liked the icons theme but these rounded corners are too much. It was perct before 🥲 Why is it copying Google Chrome? Chrome is ugly!!

Another thing I dont like is the shadow on hover and on select. Seems so simplistic now. Idk what changed.

Vyrtsev
Making moves

Can we make borders even more round, like up to 11. Maybe 1000px?

Vyrtsev_0-1792438063558.png

 

JNavas
Contributor

Version 153.5.1, first offered to ESR channel users on October 20, 2026
I confirm this release retains the user-preferred Proton UI style.

jammnrose
Making moves

Hate the overly rounded everything and new theme. Looks like a garbage AI slop written Chrome copy.

Disabled immediately. browser.nova.enabled -> false