Skip to content

fix(studio): hold a resized element's size while the timeline is rebuilt - #3135

Merged
miguel-heygen merged 4 commits into
stack/p5-mixed-colour-swatchfrom
stack/p8-resize-hold
Aug 9, 2026
Merged

fix(studio): hold a resized element's size while the timeline is rebuilt#3135
miguel-heygen merged 4 commits into
stack/p5-mixed-colour-swatchfrom
stack/p8-resize-hold

Conversation

@miguel-heygen

Copy link
Copy Markdown
Collaborator

What

A resized element keeps its new size across a seek instead of snapping back to its stylesheet size.

Why

Size does not compose the way the position offset does: both channels write width and height, so the later write wins. Standing aside meant nothing held the size while a soft reload reverted the old timeline, since GSAP hands back each tween's recorded starting width. The element sat at its stylesheet size until the new timeline rendered — the jump after a resize — and the next gesture then started from a box disagreeing with the committed vars and snapped on its first move.

How

The size reapply no longer skips GSAP-sized elements. Only an element mid-edit carries the vars, so this cannot affect anything the user is not actively resizing.

Test plan

  • Resize an element, scrub the timeline, and the size holds
  • Full suite on the composed stack: 3701 studio, 434 studio-server, 1750 core tests

Last of eight stacked PRs re-cutting #3077. The tip of this branch reproduces #3077 exactly: of the 86 files that branch changed, none differ.

Resizing the card commits correctly — the source and a fresh load both read
273x181 — but 200ms after the drop, mid-commit, the element renders at 395x261
with the studio size vars still holding 273x181. Something writes the
pre-gesture size back inline while the reload is still in flight, and every
writer of that size was silent.

Both are traced now under the existing hf-resize-debug flag, each with the size
going in, the size being replaced, and a short stack. Restoring the pre-gesture
size is right on a cancel and wrong after a successful commit, and the function
doing it cannot tell the two apart from the inside — so the caller has to be
named before this can be fixed at the right end.
Your log caught it across two resizes. The first commits 305x202 and the element
is 305x202 at the drop; 200ms later it renders 395x261, its stylesheet size,
while --hf-studio-width still reads 305. The second gesture then starts with
`actual` at 305 against a live box of 395, and its very first move — a pointer
delta of 0.1px — snaps the element back to 305. That snap is the jump.

The gap belongs to the soft reload: it reverts the old timeline before building
the new one, and GSAP hands back each tween's recorded starting width on the way
out. Nothing held the size in between, because the seek reapply that exists for
exactly this stands aside for elements GSAP animates.

Standing aside is right for the offset — those channels compose, and applying
both doubles the move — and wrong for size, where both channels write width and
height so the later write simply wins on the same committed number. It applies
now. Only an element mid-edit carries the vars, so nothing else is touched.

A test seeks an element whose size GSAP owns after the revert put the stylesheet
size back, and fails with the skip restored.
Base automatically changed from stack/p7-drag-correctness to stack/p5-mixed-colour-swatch August 9, 2026 15:40
@miguel-heygen
miguel-heygen merged commit 556250e into main Aug 9, 2026
11 of 13 checks passed
@miguel-heygen
miguel-heygen deleted the stack/p8-resize-hold branch August 9, 2026 15:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant