Firefox 156 makes scrollbar feature detection more honest

Custom scrollbars are an awkward corner of progressive enhancement: the WebKit pseudo-elements are widely used, while the standards-oriented scrollbar properties are a separate path. Firefox 156 makes one small but useful correction to the way authors can distinguish those paths. Its release notes say @supports selector(::-webkit-scrollbar) now reports false on every site, even where Firefox still applies some compatibility rules. That lets a negative feature query select standards-first styling in Firefox without pretending the entire WebKit scrollbar family works there.

What changed, and what did not

Before this change, a site could see a positive answer for ::-webkit-scrollbar in Firefox because of compatibility behavior. That answer was too broad. A stylesheet might take it to mean that the full group of WebKit scrollbar pseudo-elements was available, even though Firefox does not support the family as a complete styling surface.

Firefox 156 now reports the selector as unsupported in @supports. In the same release, Firefox can still act on ::-webkit-scrollbar rules for sites covered by its compatibility preference. Those two facts are deliberately separate: a compatibility rule may be recognized, but feature detection should not advertise complete support. This is a reporting change for a safer cascade, not a new promise of rendering parity.

Why the negative branch is useful

A common pattern uses a negative selector query to reserve standards-based scrollbar declarations for engines that do not claim WebKit scrollbar support. With Firefox 156, that condition becomes true in Firefox, so that branch can apply there. The result is a more meaningful decision point when a component has a conservative standards-first fallback and a narrower WebKit enhancement.

/* Keep the ordinary UI usable first. */
.panel {
  scrollbar-width: thin;
  scrollbar-color: #64748b #e2e8f0;
}

/* Firefox 156 now enters this negative branch. */
@supports not selector(::-webkit-scrollbar) {
  .panel {
    scrollbar-color: #0f766e #e2e8f0;
  }
}

/* Treat this as a separate enhancement surface. */
.panel::-webkit-scrollbar { width: 12px; }

The code is an organizational example, not a recipe for identical cross-browser scrollbars. Put the visible, usable baseline first. Keep vendor-specific rules local and verify the final computed styles in each target engine. If a design depends on exact thumb geometry, hover states, or every sub-part of the WebKit pseudo-element family, feature queries alone are not a substitute for browser testing.

A migration check for existing stylesheets

Search for @supports selector(::-webkit-scrollbar) and its negated form before changing anything. A positive condition may now bypass Firefox, while a negated condition may start applying there. That can be exactly what a standards-first stylesheet intended, but it is worth checking for unexpected inheritance, a conflicting scrollbar-color declaration, or a theme token that only existed in one branch.

Then test the final cascade in Firefox 156 or later, including dark mode, keyboard scrolling, high contrast preferences where relevant, and any nested scroll region. Scrollbar polish should never reduce contrast, make the thumb hard to target, or conceal focusable content. The release note is a reminder to test what a feature query says separately from what a browser happens to tolerate for compatibility.

Use the change to simplify intent, not overstate support

This update is most valuable when it removes a false signal from a carefully layered stylesheet. It does not turn ::-webkit-scrollbar into a portable standard and does not make one visual treatment correct for every browser. Keep standards-oriented declarations as the dependable layer, isolate engine-specific enhancements, and let a real Firefox check decide whether the new branch improves the component.