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

Đang mở
  • Có gì không ổn?
#495 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 6 ngày

@stephaniehobson đang làm issue này rồi.

Từ ngày 9/11/2026.

  • #497 của @stephaniehobson — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
49/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript
Lĩnh vực
testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
JavaScript
Star
21
Fork
7
Merge trung bình
6 ngày 3 giờ
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của mozilla/ensemble

Tất cả issue của mozilla/ensemble

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.