Resize timing check can start measuring before the hardware charts finish their first animation
维护者通常 6 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 49/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript
- 领域
- testing
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- JavaScript
- 星标
- 21
- 派生
- 7
- 平均合并
- 6 天 3 小时
- 30 天内合并 PR
- 8
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
mozilla/ensemble 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 6 天内回复
-
难度 2/5 1-3 小时 新手友好度 64/100
维护者通常 6 天内回复
-
难度 2/5 1-3 小时 新手友好度 35/100
维护者通常 6 天内回复
-
难度 1/5 1-3 小时 新手友好度 58/100
维护者通常 6 天内回复
-
Post-deploy housekeeping: build script order, source maps, ogimage.xcf, old static/ tree可能已有人在做 @stephaniehobson 于 1 天前认领。 未关闭
mozilla/ensemble#488 · 已指派 1 人 ·
维护者通常 6 天内回复
相似的 Issue
-
check:passed feeds:add
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 76/100
-
难度 1/5 1 小时以内 新手友好度 75/100
SACGF/variantgrid#2791 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 82/100
hiero-ledger/hiero-sdk-js#4761 ·
维护者通常 1 天内回复