Resize timing check can start measuring before the hardware charts finish their first animation

Aperta
  • Qualcosa non va?
#495 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 6 giorni

@stephaniehobson ci sta già lavorando.

Dal 9/11/2026.

  • #497 di @stephaniehobson — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
49/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
testing

Direzione di ricerca

Start with tests/playwright/specs/fixtures/resize.spec.js and src/components/views/MetricsGraphics.jsx; check whether each hardware chart receives more than one MG.data_graphic call before resizing, as the issue suggests. Then inspect how the spec starts its PerformanceObserver and how chart transitions run during page load. Done means confirming or ruling out the timing explanation and finding a way to keep the 1000 ms budget from counting chart loading work.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

testing

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.

Lingua principale
JavaScript
Stelle
21
Fork
7
Merge medio
6g 3h
PR unite (30g)
8

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mozilla/ensemble

Tutte le issue di mozilla/ensemble

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.