Repository navigation
test(interaction-harness): a late hand-off reads the caught start - #10888
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
PR Analysis Report🔎 Preview ·
|
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet. The pull request is a draft, so marking it ready for review starts CI; it already carries ci:run.
The new default is narrow and well pinned: both positive cases fail against the base harness and pass here, an explicit setBeforeBlock still wins, and a main-thread mover still fails.
Optional follow-up: busy.ts now reads the value before the caught animation's start in two places with slightly different rules (the progress replay's anchor and this default), and one shared helper would keep them aligned.
[Automated review]
cixzhang
added
the
ci:run
A busy proof excuses a hold that starts before the block and ends at the first presented change inside it, when the hold sits at the value the page set before the block (`setBeforeBlock`). Without that value, a window that caught an animation now takes the value on the cast's last frame before that animation's start. Chromium on a loaded runner also presents a just-started compositor animation late: a slider's coast first showed 25-111 ms after its start, with a catch-up on that frame. An explicit `setBeforeBlock` still wins. A hold at another value, a freeze after the first change and a main-thread mover still fail.
7b0bf5a to
2a3a5e6
Compare
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet. The pull request is a draft, so marking it ready for review starts CI; it already carries ci:run.
No blocking findings. The new default stays narrow: an explicit setBeforeBlock still wins, a hold at any other value or a frame without the element gets no excuse, and every frame after the first change is still judged.
[Automated review]
|
/approve-spec f0d7462 |
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet. The pull request is a draft, so marking it ready for review starts CI; it already carries ci:run.
No blocking findings. The merge from main leaves the patch unchanged, and the new default stays narrow: an explicit setBeforeBlock still wins, and a hold at any other value or a frame without the element gets no excuse.
[Automated review]
|
/approve-spec 7b57978 |
There was a problem hiding this comment.
Approved pending CI: CI has not run on this head yet. The pull request is a draft, so marking it ready for review starts CI; it already carries ci:run.
No blocking findings. The merge from main leaves the patch unchanged, and the new default stays narrow: an explicit setBeforeBlock still wins, and a hold at any other value gets no excuse.
- Small wording fix for the description: "the default reads dated frames, on the start's clock" holds only when a proof dates its cast from the controls' starts (a replay with an
aheadcontrol, orcontrolStarts); SliderTouch's coast proof does neither, so its frames keep the cast's stamp lag and the default reads a frame at least that lag before the start, withholding the excuse when the release shows within that lag.
[Automated review]
Maintainer impact
Under load, Chromium presents a just-started compositor animation late: in SliderTouch's coast, 25–111 ms after its start (median 57 ms). Held frames inside the judged part read as misses the control does not show. On main 738919b the proof failed: "moved on 6 of the 7 frames the control moved".
Intended invariant
A busy proof judges every frame after the animation's first presented change. Only a hold that starts before the block, at the value the animation starts from, is a late hand-off. A main-thread animation still fails.
Change
setBeforeBlocknames that value. Without it, a window that caught an animation (blockMainThread'sduring) takes the value on the cast's last frame before that start. An explicitsetBeforeBlockstill wins. No threshold, floor,minJudgedFramesor other late-start rule changes.Nothing is counted twice. The late-start rule runs before any frame is judged. A prediction (#10812) judges only from the first presented change. A Chromium cast with a control is dated first (#10887). Without the controls' starts, its dated frames keep the cast's lag, so a release shown within it gets no excuse. A held frame dated before the judged part is not judged.
Evidence
during:busy.control.test.ts: the default equals the explicit value; a mismatched value, a main-thread mover and a moved-to hold still fail. The positive pins fail on the base.Scope
Testing
WebKit runs the same specs through
internal/interaction-harness/scripts/webkit-container.mjswithCI=1 --workers=1.