Firefox and Gecko Scroll-Driven Animation Support

Firefox implements the scroll-driven animation surface as specified and, having shipped it most recently, without the legacy quirks the other engines carry. What it lacks is a layer viewer, which changes how verification works there: compositing is inferred from the absence of paint work rather than read from a panel. This guide covers what Firefox’s tooling shows, how to draw the right conclusion without a layer tree, and why a short pass in Firefox is disproportionately useful. It sits under the engine support matrix.

When to use this approach

  • Verifying an effect developed in Chromium. Firefox is the engine most likely to expose an assumption baked in by Chromium-only development, and the check is quick.
  • Confirming compositor execution. The profiler shows main-thread work clearly, which is enough to establish whether an animation is touching it.
  • Diagnosing an effect that runs but looks different. Timing and ordering differences surface here more often than elsewhere.
  • Testing a guard. Anything gated on a browser version rather than a feature query fails in Firefox first, which makes it a useful canary.

Use Chromium instead when the question is specifically about layer count or texture memory — Firefox cannot answer either directly.

What the Firefox profiler shows Four things to observe and whether Firefox exposes them. Frame timing and main-thread work are fully visible in the profiler. The animation inspector shows effects and their timing. There is no layer viewer, so compositing is inferred rather than observed, and there is no per-layer memory figure at all. available? Frame timing and dropped frames profiler Main-thread work and long tasks profiler Running animations and their timing inspector Layer tree and texture memory not exposed Compositing is inferred from the absence of paint work rather than read from a panel.

Implementation

1. Record a scroll in the profiler

Start a recording, scroll through the animated section at a normal reading pace, and stop. The two tracks that matter are the main thread and the frame timing; everything else is detail for a different investigation.

2. Infer compositing from what is absent

Inferring compositing without a layer panel Two profiler traces of the same scroll. A compositor-driven animation produces no paint markers and no style recalculation during the gesture. A main-thread animation produces a repeating pattern of style and paint markers at frame intervals, which is the signature to look for. Compositor-driven no paint markers, no style recalculation Main-thread style and paint at frame intervals — the signature The absence of work is the evidence. It is less direct than a layer panel and reaches the same conclusion.

A compositor-driven animation produces no style recalculation and no paint markers during the gesture. A main-thread animation produces both, at frame intervals, in a repeating pattern that is unmistakable once you have seen it.

This is a slightly weaker signal than reading a layer tree — it tells you the main thread is not involved, not which elements were promoted — but for the question that actually matters it is sufficient.

3. Use the animation inspector for attachment questions

The inspector lists running animations with their timing. A scroll-driven effect that has fallen back to the document timeline shows a duration; one that resolved correctly does not behave like a timed animation at all. This is the most direct way to catch an unresolved timeline in Firefox.

4. Run the portable frame measurement 

let last = performance.now(), worst = 0;
(function frame(now) {
  worst = Math.max(worst, now - last);
  last = now;
  requestAnimationFrame(frame);
})(performance.now());

Because the tooling differs between engines, a measurement that works identically everywhere is what makes cross-engine comparison meaningful. Record the worst frame through the same section in each engine and compare the numbers rather than the traces.

5. Check the guards

What Firefox uniquely reveals Three assumptions Firefox tends to expose. An effect that relied on generous automatic promotion may not be promoted. An effect that depended on Chromium timing may reveal an ordering assumption. And a feature guarded by a version check rather than a feature query fails there first. Promotion assumptions an effect that relied on being promoted automatically may simply not be Ordering assumptions code that happened to work because of Chromium's scheduling shows its dependency here Guarding assumptions anything gated on a version rather than a feature query fails in Firefox before anywhere else Ten minutes in Firefox finds problems that would otherwise be reported by users months later.

Verification

Confirm the animation attaches: open the animation inspector and check the effect is listed and behaves as a scroll-driven one rather than a timed one.

Confirm the main thread is idle: record a scroll and check for the absence of style and paint markers through the gesture.

Confirm the numbers agree: run the portable frame measurement and compare the worst-frame figure against the same measurement in Chromium. A materially worse figure in Firefox usually means an element is not being promoted there, which points at making the promotion explicit rather than at anything Firefox-specific.

Finally, disable JavaScript and reload. Everything in a well-built scroll-driven page should still render its baseline, and Firefox’s per-site JavaScript toggle makes this a five-second check.

Edge cases and gotchas

No layer panel means over-promotion is invisible. Firefox promotes layers and will not show you them. An audit for unnecessary will-change hints has to happen in Chromium, and the fix benefits Firefox equally.

will-change matters more where promotion is conservative. An effect that Chromium promotes automatically may not be promoted in Firefox, in which case an explicit hint — scoped to the interaction — is the correct fix rather than a workaround.

Wheel scrolling produces larger deltas. Firefox’s default wheel behaviour moves in larger discrete steps than trackpad scrolling, so an effect can look continuous on a laptop and stepped on a desktop. Test with both.

Scroll anchoring interacts with growing sections. Firefox applies scroll anchoring assertively, which is generally helpful and occasionally shifts a view timeline’s derived range when content above it changes size. Reserving space for late-loading content avoids it.

The profiler samples. Very short paint events can fall between samples. A clean trace at the default sampling interval is good evidence rather than proof; increase the sampling rate when a result looks too clean to believe.

Browser-specific notes

Firefox implements timeline attachment, ranges and the view transition surface as specified, with same-document view transitions behind a flag in current stable builds. That flag status is the main reason a view-transition page needs a fallback path rather than an assumption — and a fallback that is exercised in Firefox is a fallback that is genuinely tested.

Compared with Chromium, Firefox promotes fewer elements automatically. In practice that means a page tuned in Chromium can be doing more main-thread work in Firefox than its author realises, and the profiler will show it. The fix is an explicit, scoped hint rather than an engine branch.

Compared with WebKit, Firefox’s desktop behaviour is far more forgiving of memory, so it will not reveal the texture-eviction problems that iOS Safari surfaces. The three engines each catch a different class of problem, which is exactly why a short pass in each is worth more than a long pass in one.

Frequently Asked Questions

Is Firefox’s implementation slower?

Not inherently. Where a difference shows up, it is usually a promotion difference rather than an execution one — the same animation running on the main thread in one engine and the compositor in another will obviously differ. Making the promotion explicit closes the gap without any engine-specific code.

How do I check layer count in Firefox?

You cannot, directly. The pragmatic approach is to audit promotions in Chromium — where unnecessary ones are visible — and rely on the fact that removing waste helps every engine. What Firefox can tell you is whether the main thread is involved, which is the more important of the two questions.

Does Firefox support timeline-scope?

Yes, alongside the named-timeline properties in current stable builds. As always, guard on the feature query rather than the version, because that is exactly the kind of assumption that fails on the browser you tested least.

Is it worth testing mobile Firefox?

For most sites, no — its share is small and it shares the engine with desktop Firefox. The mobile engine worth the extra pass is WebKit on iOS, because its constraints are genuinely different rather than merely a different rendering of the same behaviour.

What is the quickest useful Firefox pass?

Five minutes covers most of it. Load the animated pages, scroll each one at reading pace, and watch for anything that behaves differently from your reference engine. Then open the animation inspector on one effect per page to confirm it is scroll-driven rather than timed. Then disable JavaScript and reload one page to confirm the baseline holds.

That is enough to catch unpromoted effects, unresolved timelines and version-gated guards — the three classes of problem Firefox reveals most often. A full profile is only worth doing when that pass finds something.

Does Firefox handle reduced motion differently?

The media query behaves identically, and Firefox’s DevTools offer a simulation for it in the same way the other engines do. What differs is the platform mapping underneath: on Linux in particular, the desktop environment’s animation setting reaches the engine inconsistently, which makes Firefox on Linux a useful place to verify that your override works when the query is set by emulation and that nothing depends on it being set by the system.

Up: Animation Performance: Engine Support Matrix