Repository navigation
Resize timing check can start measuring before the hardware charts finish their first animation #495
Description
tests/playwright/specs/fixtures/resize.spec.js (added in #409) failed all three attempts in CI on #493: https://github.com/mozilla/ensemble/actions/runs/42708249217/job/129470673505. It measured 1095, 6946 and 1023 ms of long tasks against a 1000 ms budget. #493 does not change anything this test exercises: the same commits passed CI on another branch a few minutes later, main passes, and the spec passes 8 out of 8 runs locally.
The test starts its PerformanceObserver once the last chart's <svg> is visible. That may be too early. In src/components/views/MetricsGraphics.jsx, the first draw in componentDidMount is not animated (metrics-graphics defaults to animate_on_load: false), but any later update with different data is: transition_on_update defaults to true, which means a 1000 ms line transition. If a chart is drawn and then redrawn with new data while the page loads, that transition can still be running when measuring starts, and its cost gets counted against the resize. 6946 ms is close to the roughly 6 s the spec's comment gives for animating lines on resize, which fits this explanation. It hasn't been confirmed.
Two possible fixes, keeping the 1000 ms budget:
- Before starting the observer, wait until no chart transition is still running, for example by waiting until the line paths stop changing or by checking for active d3 transitions.
- Or wait for the main thread to go quiet first: start a long-task observer and only begin the resize sequence once no long task has been reported for some interval.
Checking first whether the hardware charts really do get an animated update during load (more than one MG.data_graphic call per chart before the resize starts) would confirm or rule out this explanation.
Activity
stephaniehobson commentedon Nov 9, 2026
I checked the explanation above before trying either fix, and it doesn't hold. No chart animates during page load. The failures come from a fixed wall-clock budget measured on a slower runner, and from tracing on the retry.
I ran the steps from
resize.spec.jswith a probe that records every write to a.mg-main-linepath'sdattribute and every long task:dwrites before measuringdwrites during resizedwrite before measuring starts. That's oneMG.data_graphiccall per chart and no transition, which would writeddozens of times per line. This held at every throttle level.playwright.config.jssetstrace: 'on-first-retry', so attempt 2 runs with tracing. Tracing slows eachsetViewportSizestep pastChartContainer's 150 ms resize debounce, so every chart redraws at each of the seven widths instead of once at the end. The writes are exactly 7 × 95, so it's seven full redraws, not animation frames. That it lands near the spec's ~6 s figure for animated lines is a coincidence.Both fixes proposed above wait for a transition that never runs, so neither would help.
New direction
Assert what the test is meant to guard instead of timing it. The spec's comments name two regressions: lines animating on resize, and charts redrawing on every resize event. Both can be checked directly by counting line redraws during the resize sequence: exactly one per chart, with no transition frames. That doesn't depend on runner speed. The 1000 ms long-task budget goes, or becomes a much looser backstop. Turning tracing off for this spec would also keep the retry's conditions the same as the first attempt's.
Count chart redraws instead of timing the resize check (#495)
Count chart redraws instead of timing the resize check (#495)