Five Years Behind a Flag

In Firefox 89, Compact Mode moved from a visible density choice to a hidden preference. People who found it through about:config could put the option back in the customization panel, where its new name made the arrangement clear: Compact mode (not supported).

The code stayed. The promise around it changed.

Mozilla's original decision record described a familiar product tradeoff. The Firefox team was redesigning the browser and wanted to focus its effort on one tab experience. Compact Mode was difficult to discover, assumed to have low engagement, and expensive to carry through the new design. The proposal used screen-height telemetry to argue that the default left enough room for the web even on a 768-pixel-tall display.

The discussion beneath that decision complicated the measurement. People used the denser interface on old laptops, large monitors, scaled displays, and screens crowded with bookmarks. Some wanted more page area. Others simply preferred the browser controls to recede. Several noted that a hidden setting cannot produce much engagement data from people who never learn it exists.

The eventual compromise preserved Compact Mode for existing users and placed it behind the advanced preference for everyone else. It would remain available, documented, and explicitly unsupported.

That last word matters more than the survival of the checkbox.

A preference can continue working for years because nobody removes its code. Support is the surrounding practice: testing new menus against it, checking focus and target sizes, including it in design reviews, and treating a regression as product work rather than the cost of choosing an old path. An unsupported option gives the person a way to keep their arrangement while transferring the maintenance risk to them.

I understand the temptation. Every visual mode multiplies the places a design system has to hold together. A new panel, icon, locale, pointer target, or platform convention has to work across the variants. One coherent default is easier to build and easier to explain.

But interface density is not only decoration. It changes how many bookmarks fit before scrolling, how many tabs remain legible, how much of a spreadsheet or document stays visible, and whether browser chrome feels like a tool or a tenant. People develop muscle memory around those proportions. A product may call the choice cosmetic while the person has already made it part of how work fits on a screen.

Five years later, Mozilla has brought Compact Mode back as a supported part of its new Firefox design. The announcement calls the mode heavily requested and says that every pixel matters in an interface where people spend their day. That is a small reversal with a useful shape: public feedback did not merely produce an acknowledgment or a workaround. It eventually changed what the product says it will maintain.

The return is already showing why the distinction matters. An open Firefox 157 bug reports that menus inside Compact Mode have become roomier, forcing people with long bookmark lists to scroll more. The report is unresolved. It does not prove the redesign failed. It shows that restoring an option and supporting a way of working are separate jobs.

Compact Mode should not become the universal default. Larger controls can improve readability and touch access, and many people will prefer the roomier design. The important choice is not between dense and spacious interfaces. It is whether a product presents customization as a temporary escape hatch or accepts the quieter obligation that arrives when people organize their days around it.

The setting is visible again. Now the ordinary work begins: deciding, menu by menu, what compact is supposed to mean.