290 Commits

Include renames

Author	SHA1	Message	Date
Miguel Ángel	896bc336a2	feat(studio): show every colour of a mixed selection in the swatch (#3144) ... * feat(studio): show every colour of a mixed selection in the text swatch Selecting text painted in more than one colour showed a white swatch. The toolbar reads a property only when the whole selection agrees on it, which is right for bold and italic (a toggle is on or off) but wrong for a swatch: with nothing to report it fell back to the default, so a red-and-green selection claimed to be white. The swatch now reads the colours as they run through the selection and draws one band per run, sized by how many characters carry it. Hard stops, not a fade — it reports the colours that are there, and a blend would draw colours that are not. A single-colour selection is a plain swatch, as before, and picking a colour still applies it to everything selected. * feat(studio): blend the mixed-colour text swatch instead of banding it Bands read as two separate swatches sitting next to each other. Each colour now sits at the middle of its share and the browser fills between them, so the control looks like one swatch holding a mixed selection. * fix(studio): keep whitespace out of the text colour swatch Colouring a whole element and then recolouring one word inside it leaves the spaces around that word carrying the first colour. The swatch counted them, so a red word inside green text drew a sliver of green, then red, then green — the element's colour appearing at an edge where no glyph is painted in it. Whitespace paints nothing, so it no longer contributes a colour. The swatch shows the colours the glyphs are actually drawn in, in the order they appear. * fix(studio): stop the colour swatch repeating its gradient under the border The swatch grew a green edge on its red side and a red edge on its green side. `background` maps a gradient to the padding box and then repeats it to fill the border box, so the 1px ring showed the strip either side of the tile: the gradient's end colour along the leading edge, its start colour along the trailing one, both read as a mirrored copy of the swatch. Painting from the border box instead gives the ring the colour the glyphs next to it are actually drawn in. * fix(studio): drop the highlight when a text edit closes Picking a word with a double press and then clicking away left the word painted grey. The element was no longer being edited, but the text still read as selected. Ending the edit removed contenteditable and blurred the element, and neither of those drops the browser's own selection. It now clears the selection as part of the teardown, and only when the selection lives inside the element being closed — one somewhere else in the preview belongs to whatever put it there. * feat(studio): match the mixed-colour swatch to the one in the design tool The swatch drew a proportional blend along the horizontal: each colour took the share of the sweep that its characters took of the selection. At 16px that reads as one muddy smear, and a colour used by a single character is almost invisible — the opposite of what the control is for, which is answering "which colours are in here". It now sweeps diagonally through each distinct colour, evenly spaced, the way the mixed-colour swatch works in the design tool this sits alongside. A colour appears once however much text carries it, and the dot itself matches that reference too: 16px, a 2px ring, and a small lift on hover. The character counts had no other consumer, so the reader hands back the distinct colours in document order rather than counting. * fix(studio): harden mixed-colour text swatches * refactor(studio): split inline text style readers	2026-08-11 04:26:31 -04:00
Miguel Ángel	4cc46f5f9f	feat(studio): edit and style text in the preview (#3143) ... * feat(studio): edit and style text in the preview Double-press a text element in the canvas and the caret opens where you pressed, in the element itself rather than in a panel. Select characters and a small toolbar offers colour, bold, italic and underline, applied to exactly those characters. The toolbar lives in Studio's document rather than the composition's. Putting it in the preview would inject Studio's chrome into the user's composition, where a render would capture it and the composition's own styling would inherit into it. In a flex or grid container the rebuilt runs go inside one wrapper, so a coloured word cannot reflow the element it sits in. Also fixes the keyboard: the shortcut guards matched contenteditable=true only, so playback shortcuts ate letters typed into the composition. * refactor(studio): keep domEditingLayers under the size cap The rich-text operation pushed this file past the 600-line gate. Same change the branch made later, landed with the commit that caused it. * test(studio): wrap selection changes in act * fix(studio): restore rich text after failed save * fix(studio): polish inline text editing * fix(studio): harden inline text editing	2026-08-11 03:54:18 -04:00
Miguel Ángel	20d915938b	feat(studio): ask for feedback when a render ends, not on a session counter (#3205) ... ## What Studio's feedback prompt now fires when a render finishes or fails, instead of on a session counter, and the reports it collects carry enough context to act on. - Replaces the 32px inline bar with a card in the existing toast stack - Adds `studio_feedback_shown` / `studio_feedback_dismissed` / `studio_feedback_interview_click`, so the funnel is visible - A failed export and a crash skip the 0-10 score and ask what happened - Adds a crash prompt to the error boundary - Attaches a breadcrumb trail, render settings and outcome, and how the project was created ## Before / after <img width="1500" alt="Before: a 32px feedback strip pinned under the preview. After: the feedback card in the toast stack, with one-tap answers, and the red variant for a failed export." src="https://github.com/user-attachments/assets/29e2373f-ee96-42c4-b006-ab9a0e56a60a" /> The old bar's rating numbers are `neutral-600` on `neutral-900/80`, which is why it reads as a disabled row rather than a control. **In the running Studio** — bottom-right, sharing the toast stack, hovering a chip explains it on the line above the input: <img width="1500" alt="The feedback card in the bottom-right of the running Studio, with the rotated follow-up question and a hovered chip explained inline." src="https://github.com/user-attachments/assets/3969da50-cc7a-466a-bbf9-b151a1bc1d5d" /> **On the crash screen** — the prompt the error boundary renders, asking what the user was doing rather than what went wrong, since the stack trace already covers the latter: <img width="1200" alt="The Studio crash screen with the feedback card below the Try again and Reload Studio buttons." src="https://github.com/user-attachments/assets/4d287011-9c19-4b94-99d0-07a0388fb39c" /> | | Before | After | |---|---|---| | **Trigger** | Every 10th session | A render finishing, failing, or a crash | | **Placement** | 32px inline bar, pushes preview up | Card in the toast stack, no layout shift | | **Rating targets** | 11 bare buttons, `neutral-600` | Native radios, resting fill, `neutral-400` | | **Follow-up** | Free text or nothing | One rotated question, four to seven one-tap answers | | **Option help** | None | Inline hint on hover and focus | | **Press feedback** | None | `active:scale-[0.97]`, 150ms ease-out | | **Keyboard** | No exit path | Escape closes, Enter sends, arrows move the rating | | **Auto-dismiss** | 20s, always | 30s, cancelled the moment you interact | | **Failure case** | Same NPS question | Its own question, no score, error quoted back | | **Crash case** | Nothing | Prompt on the crash screen | | **Visibility** | Submissions only | Shown / dismissed (with reason) / submitted / interview click | | **Report content** | Rating, comment | Plus breadcrumbs, render settings and outcome, project provenance | ## Why The old bar fired on a session count, so it interrupted at a moment with no subject: nothing the user had just done, nothing to have an opinion about. It also emitted nothing when it appeared or when it was dismissed, which made the collection rate impossible to diagnose. A prompt nobody answers and a prompt that never renders looked identical from the outside. Visually it read as a disabled row: 11 buttons at 11px in `neutral-600` on a dark strip, with no resting affordance. And appearing mid-task pushed the whole preview stack up, which the old code carried a comment apologising for. Separately, the reports it did collect were not actionable. A comment says what went wrong; it almost never says how to get there. ## How **One trigger, one owner.** `feedbackTrigger` owns eligibility and nothing else does: once per tab, thirty days after an answer, seven after a dismissal, never when telemetry is off (prompting someone whose response we would then drop wastes their attention). `VITE_HYPERFRAMES_NO_FEEDBACK=1` still disables it entirely. **One hook, every failure path.** The trigger watches the render job list rather than each of the four places a render can finish (server rejection, unreachable server, SSE terminal event, SSE connection drop), so paths added later are covered without touching the trigger. Renders loaded from disk history never fire it. **Reuses what exists.** The card wears `StudioToast`'s glass treatment and joins its stack, so there is no second visual language and no new CSS. The rating row is native radios, which gives arrow-key navigation, grouping and labels for free. **One question each, rotated across users.** A corner card that asks three things gets answered by nobody. Each person gets one follow-up with one-tap answers, explained on a reserved line rather than a floating tooltip (the card is 340px in a corner; a bubble above the chips lands on the question, below lands on the input). Detractors are never given a rotated question, because they already have a specific complaint. Every option was checked against the code: an option naming a feature Studio already has would collect taps meaning "I could not find it", which is indistinguishable afterwards from "it does not exist". **Breadcrumbs cost one line.** Every studio event already flows through `trackEvent`, so recording the trail there needs no new instrumentation and stays correct as events are added. **Provenance lives outside React.** A crash unmounts the tree, so it is captured when the project loads and read from module scope when the crash prompt renders. ### Privacy Breadcrumbs and provenance carry names, enums and counts only. Values are copied from a fixed allowlist of short keys, and anything longer than a slug is dropped rather than truncated, so comments, file paths, stack traces and project titles cannot reach them even if a future event carries one. Tests assert this. ### Where these responses land Studio feedback goes to PostHog and nowhere else, which is what it did before this change too. Worth stating because the CLI behaves differently: `hyperframes feedback` also forwards to the backend feedback endpoint via `submitFeedback`, on top of its PostHog event. Studio has never used that path, before or after this PR, so if you read CLI feedback anywhere other than PostHog, Studio responses will not show up there. Nothing here changes that either way. Whether the two surfaces should share a delivery path is a product question, not a defect in this change, and closing it would need a field on the backend DTO: it is shaped around `cli_version`, and Studio reports from a crash or a failed export deliberately carry no rating. ## Test plan - [x] Unit tests added/updated - [x] Manual testing performed - [ ] Documentation updated (if applicable) **Unit** — 39 new tests: trigger eligibility and cooldowns, the detractor override, rotation, preset shape and the no-brands rule, breadcrumb rolling and privacy, provenance parsing and its failure modes, and the crash boundary rendering the prompt with no rating input. **Live** — both render paths driven end to end against a running Studio on a production bundle, with real renders. Every PostHog request was intercepted and dropped, so nothing reached the project. Verified the emitted payload for a finished render, a failed export, the rotated follow-ups, each chip's hint, and the interview link. **Not covered** — no live capture of a spontaneous crash. Three attempts to force one failed because Studio's guards held and it kept rendering, so the crash path is verified by component tests rather than by driving it. Touch devices see chip labels without hints, since the hint is revealed on hover and focus.	2026-08-11 01:33:52 -04:00
Miguel Ángel	17ac986bfe	fix(studio): canvas selection, drag and resize correctness (#3146) ... * fix(studio): size the selection box by the transform the element actually paints under The box around a text layer inside the playground card stopped mid-word. The layer is 260px wide and paints 313, because its parent carries `scale(1.2)`, and the chrome read only the element's OWN transform. The top-left looked right, since the corners are anchored to the real bounding rect, so only the right and bottom edges fell short, by exactly 1/1.2. The same read decides whether to draw the box rotated at all, so an element whose parent is rotated got an upright box over a rotated one. The transform is now accumulated from the element up to the composition root. Only the linear part matters: each transform's origin contributes translation, and translation is already discarded by matching the corners to the element's bounding rect, so composing the matrices is enough and no per-ancestor origin has to be unpicked. The walk stops inside the composition document, because the canvas zoom lives on the iframe in Studio's own document and is applied separately. The fake DOMMatrix the geometry tests use gained the `multiply` it now needs. * fix(studio): drag by the movement the element actually makes, not the one assumed An element that had never been dragged skipped the movement measurement and took the canvas zoom as the whole screen mapping. Nothing above the element was considered, so any parent transform broke the drag: a card at rotationY 180 with scale 1.2 maps a rightward drag to -1.2x the zoom, meaning the text walked LEFT while the overlay followed the pointer, and the overlay only snapped onto the text at drop, when it re-measured. Measured on the live element in that card: one unit of drag offset moved it -0.757 px on x and +0.757 on y, where the skipped path assumed +0.631 on both. The measurement it skipped already handles this — it moves the element, watches where it lands, and inverts that, which is right for rotation, mirroring, scale and perspective alike. So the special case is gone and every drag measures. Same element after: a 120x80 pointer drag moves it 120.3x80.2. Rewrote the test that asserted the skipped path's identity matrix for an unmovable element. It now asserts the honest outcome: an element with no measurable movement is reported unmeasurable whether or not it carries a path offset, and the caller's existing fallback covers it. * fix(studio): shift-click adds the element under the pointer, not the last one hovered Shift-click read the hover cache and used it without checking what it described. That cache is filled asynchronously as the pointer moves, so passing over one element on the way to another leaves it naming the element you left. The shift-click then added THAT element, and because the same branch prevented the default and set the suppression flags, the mousedown path that would have resolved the point correctly never ran. Multi-select looked like it grabbed things at random, or like it did nothing. Reproduced on the canvas with a trace: hover #card, shift-click #dot-b, and the group gained #card. Same gesture after: the guard rejects the cache, the mousedown path resolves the point, and the group gains #dot-b. The cache is still used when it is provably about the point clicked, including when it names a clip ancestor of the element there, so the fast path survives for the common case of clicking straight at something. Adds `hf-select-debug` (localStorage, off by default) recording which selection branch ran and what it decided, and pulls the flag/format shared with `hf-reload-debug` into one place rather than copying it. * fix(studio): keep every element a marquee caught, not just the first The marquee built the group correctly and then threw it away. It announced only the primary to the timeline, and the timeline is the source of truth for what is selected: the sync back to the canvas saw one selected id against a group of several, decided the canvas was stale, and replaced the group with that single element a moment after the drop. Drag a box around four things, get one. The whole set is announced now, and the primary goes in as its anchor rather than as a new single selection, so the set it just joined survives. This is the same reason the single-select path already anchors with preserveSet. A test drives applyMarqueeSelection with two elements and asserts both reach the timeline; it fails against the old single-id announce. * fix(studio): stop a group selection from erasing itself on the timeline Every canvas selection is mirrored onto the timeline, and the timeline syncs back — whatever it holds replaces the canvas selection a moment later. The mirror announced only the primary and anchored it with preserveSet, but preserving a set that does not contain the id empties the set, and an empty set syncs back as "nothing is selected". Adding a second element, or re-resolving a group after moving it, could therefore drop the whole selection rather than keep it. One helper now owns the mirror: publish the members, then anchor. A single selection keeps the previous contract deliberately, so a late async primary still cannot collapse a live group and a fresh click still collapses a stale one. The group re-resolve path also gains the ancestor id fallback the other callers already had — without it a member with no direct timeline row resolved to null and deselected everything. Two tests: a second element joining a selection, and a marquee, both assert the full set reaches the timeline. Both fail against the announce-the-primary-only version. * chore(studio): trace what moves a dragged group and when A drag that jumps is a position that changed without the pointer asking for it, and nothing on that path says anything today, so the frame it diverges can only be guessed at. `hf-drag-debug` (localStorage, off by default) records the whole gesture: the mapping and start position each member got, the pointer delta against the delta actually applied on every eighth move, what each member was told to commit, and where they all sit at the drop, once the commit resolves, and 120/400/900ms later. That last group is the point of it. The source write, the preview reload and the timeline resume all land within a few frames of the drop, and any of them can put the elements back where they started before the new position arrives — a snap-back shows up as a settle sample reverting to the gesture-start reading. A gap between `pointer` and `applied` instead means snapping pulled the group off the cursor, which is a different fault with a different fix. * chore(studio): name the path that clears a selection after a group move The drag trace showed the group landing exactly where it was dropped and staying there — no snap-back at any settle sample, and the pointer and the applied delta never more than 2px apart — but two milliseconds after the drop the selection was cleared with seven members still in it. The clear comes from the timeline sync deciding the timeline holds nothing, and that branch said nothing. It says so now, along with whether it is about to act on it. The mirror alongside it reports how many members it managed to publish and whether the anchor was among them, because a member with no timeline row of its own resolves to null and is dropped silently — publish none and the sync reads it back as an empty selection. * fix(studio): losing one member of a group no longer deselects all of it After a move the preview re-syncs and the selection is re-resolved against the new document. When the primary could not be found there, both re-resolve paths cleared the entire selection — so a group of five, all still on screen, was deselected because one of them failed to resolve. The trace showed the clear landing 600ms after the drop with five members still held, and the timeline sync running afterwards on an already-empty canvas, which ruled it out as the cause. A live group now re-resolves as a group and keeps whoever survived, picking a new primary from them; it only clears when nobody did. That is what refreshDomEditGroupSelectionsFromPreview was written for — it existed and was never called. Both clears also say which one they are and how many members were held, so if this is not the last of it the next trace names the path immediately. * feat(studio): carry a multi-selection in the URL, and name the member that breaks away A link to a bug hit with several elements selected only reproduced one of them, so the report read as "works for me". The hash now carries the rest as selGroup and reopens the whole selection; members whose element is gone are dropped rather than failing the others. Verified end to end in a real browser: select three, copy the hash, open it fresh, the same three come back. The drag trace also gains a rigidity check. A group moves as one object, so every member travels the same distance; one that does not IS the fault. Drift was being computed but only printed on every eighth frame, which is exactly how a single-frame divergence hides — it now prints on the frame it happens. The frame handler moves to its own module on the way past. It had grown a snap block and a trace block inside a function already juggling four gesture kinds, and it was over both the complexity and file-size gates. Not fixed: the jump itself. Two headful runs driving a real group drag showed the members staying rigid to the pixel, at the drop and 900ms after, so I have not reproduced it yet and will not guess at a fix. * fix(studio): stop snapping from moving a selection you have not dragged yet Your log caught it on the first frame of the drag: pointer "0,0", applied "4,-3", and all four members jumped 12,-8 composition px before the pointer had moved at all. An element resting within the 6px snap threshold of a guide is already snappable, so the snap computed on frame one closes that gap immediately — picking the selection up moves it. Snapping now sits out until the gesture has travelled the same 4px a drag needs to count as a drag rather than a click, on both the group and single-element paths. Nothing below that distance moves anything, and a real drag snaps exactly as before. The test builds a box resting 4px from a guide and asserts the ungated call still returns dx 4 — the very displacement from your log — while the gated one returns 0 for a pointer that has not moved. * fix(studio): a dropped group stays selected Your Jam confirmed the first-frame jump is gone — pointer "0,0" now reads applied "0,0" — and caught what was left: two milliseconds after each drop, a `[hf-select] clear` with the group still holding three, then four members. Every pointerup trails a click. The group gesture ref is cleared before the commit runs, so by the time that click arrives the box no longer looks busy and it reaches the canvas as an ordinary click — landing in the gap between the members, resolving to nothing, and clearing the selection the drag just moved. The under-threshold path already ate that click; the committed path never did. The flag is now set before the two paths diverge, so neither can forget it. The test drives a real pointerup through the handlers and fails on the committed path with the flag moved back down. * feat(studio): marquee from anywhere on the canvas, including outside the frame An element dragged past the edge sits out in the grey, and the rubber band refused to start there — it only began when the press landed inside the composition rect. The one gesture that could reach those elements could not be begun near them, so the timeline was the only way to select something plainly visible on screen. The collecting half never had that limit: it compares rects in overlay space and never clipped to the frame, so those elements have always been selectable once the band could begin. Only the start gate had to go. A press in the grey that never travels still commits an empty selection, which is the deselect it used to be, so the old behaviour of clicking out there to clear is unchanged. * refactor(studio): keep the selection files under the size cap The selection work above pushed four files past the 600-line gate. Same split the branch made later, landed with the changes that caused it. * fix(studio): preserve selector groups in share URLs * fix(studio): close multi-selection review gaps * fix(studio): stabilize selection store reads * fix(studio): preserve canvas-only group anchors * fix(studio): stop a group drag from jumping one element back Dragging several elements at once and dropping them made one of them snap back to where it started for a frame or two, then jump forward again. Each member of the group is written separately, and every write patched the live GSAP tween in place and then seeked the player. A seek re-renders the WHOLE timeline, not the tween that changed, so the members still queued behind that write got repainted from their un-patched tweens: back to their pre-drag position, where they sat until their own write landed. Only members whose tween actually renders at the playhead showed it, which is why a group of three flashed one element and left the others still. The group commit now defers the seek for every member but the last, so the queued members keep the transform the gesture left on them and the whole group repaints once, from the fully patched timeline. * perf(studio): commit a group drag in one request Dragging N elements cost N writes and 9 reads for a three-element group: each member fetched the composition's parse to preflight, fetched it again to resolve its tween, then wrote the file on its own round trip. Every one of those writes re-read, re-parsed and re-serialized the whole composition. Three changes, same behaviour: - The parse endpoint shares an in-flight request per file, so callers asking for the same composition at the same moment get one request. Only overlapping calls share — the entry is dropped as soon as it settles, so a read after a write still gets a fresh parse. - The group preflight runs its members together instead of one at a time. A preflight writes nothing, so there is nothing to order. - Members' mutations are queued and sent as one batch write. Anything that re-reads the file flushes the queue first, so a member resolving a shared or stale tween never reads a composition missing writes it is about to build on. The batch carries each member's runtime patch, and only the last one re-renders. A three-element group drag now issues 2 reads and 1 write, down from 9 and 3. * fix(studio): harden batched drag commits * fix(studio): carry deferred preview fallbacks * chore(studio): name whoever puts the pre-resize size back 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. * fix(studio): hold a resized element's size while the timeline is rebuilt 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. * refactor(studio): keep the resize files under the size cap * docs(studio): fold the resize note into the size-reapply comment * fix(studio): rotate the child outlines with the element they outline Selecting a rotated element drew upright dashed boxes across its children: the chrome co-rotated with the element and the child outlines did not, so a text layer inside a rotated card got a square outline lying across the rotated glyphs. The chrome already measures an oriented box; the child outlines were still measured axis-aligned. They now use the same oriented measurement and render with the same rotation. An unrotated element measures identically to before, since the oriented rect returns the plain bounding box at angle 0.	2026-08-09 16:58:34 -07:00
Miguel Ángel	bea32b8aae	fix(studio): stop a Studio edit from reloading the preview (#3137) ... * fix(studio): stop a Studio edit from reloading the preview as if it were external Every mutation route wrote the file without leaving a write receipt, so the watcher's broadcast of Studio's own edit arrived with no identity on it. The external-change coordinator could not tell that echo from an agent or an editor writing the file behind Studio's back, so it took the safe branch and did a full iframe reload. That reload hides the stage for the length of the reload, which is what the flash after a text edit was. Every mutation write now goes through one helper that records the receipt, and the client claims the write before the request goes out rather than after it: the server writes and the watcher fires while the request is still in flight, so a token marked from the response can arrive after the echo it was meant to match. Reproduced in the browser before and after, with the reload path traced end to end. Before, a patch-element write logged `token: null` then a reload from the coordinator; after, the same write logs the token and `suppressed: own write token`, with no reload. Adds `hf-reload-debug` (localStorage, off by default) alongside the existing `hf-resize-debug`: it records each file-change decision and its reason, plus the stack of whoever asked for a full reload. * fix(studio): claim the timeline and caption writes too, not just the DOM ones The receipt only helps when the client marked the token it sent, and the GSAP mutation writers never sent one. A drag commits through gsap-mutations, so the server minted a token the client had never seen, the change came back looking like someone else's, and the preview did the full reload the receipt was meant to prevent. Same one-line claim on both GSAP mutation writers, the timing sync's mutation call, and the caption auto-save PUT. The rollback call stays deliberately unclaimed and says why: it runs because a mutation did not converge, so the preview is on bytes nobody can vouch for and the reload is the point. Verified live: a drag-shaped update-properties on the timeline now logs `suppressed: own write token` with no reload, where it logged a coordinator reload before. * refactor(studio): keep timelineTimingSync under the size cap Claiming the timeline writes pushed this file one line past the 600-line gate. Same change as the branch made later, landed with the commit that caused it. * fix(studio): cover remaining write receipt paths * fix(studio): preserve batch write receipts * fix(cli): emit every file in a watcher burst	2026-08-09 19:10:02 -04:00
Miguel Ángel	d8a91fc347	fix(studio): stop three crash-boundary trips in the editor (#3102) ... ## What Fixes three Studio crashes. All three throw into React and drop the user on the full-screen "Something went wrong" boundary. **1. `NotFoundError: Failed to execute 'removeChild' on 'Node'`** — the highest-reach of the three. The `Player` mount effect appends a `<hyperframes-player>` into its container and tears it down with `container.removeChild(player)`. By the time that cleanup runs the element may already be detached: the container can re-render, a crossfade refresh can swap it, or a translation extension can reparent it. Switched to `player.remove()`, a no-op when the node has no parent. `utils/clipboard.ts` had the same unguarded `document.body.removeChild(textarea)` and is fixed with it — those are the only two `removeChild` call sites in non-vendor source. **2. `SecurityError: Failed to read the 'localStorage' property from 'Window'`** — `getPersistedTab()` read `localStorage` unguarded and runs as a `useState` initializer. Chrome throws on the *property read itself* when site data is blocked for the document, so a profile with storage blocked lost the whole editor instead of one remembered tab. Routed through the existing `safeLocalStorage()` helper with the access guarded too, matching the pattern `telemetry/config.ts` documents. The `setItem` on tab switch was unguarded the same way and is fixed with it. **3. `TypeError: s.indexOf is not a function`** — `pruneKeyframeCacheToFiles` calls `key.indexOf("#")` on a key that is not a string, though `keyframeCache` and `gsapAnimations` are both typed `Map<string, …>`. ## Why None of the three loses real work — they are incidental teardown, persistence, and cache-pruning paths taking down the whole editor. The `removeChild` one reaches by far the most users. ## How ### Locating #3 The Studio build ships no sourcemaps, so the reported frame in a minified chunk was not traceable as-is. Checking out the `v0.7.90` tag and rebuilding it reproduces the same asset filename hash **byte-for-byte**, which confirms the rebuild is the same code the crash came from. Decoding the frame against that bundle lands on `gsapKeyframeCacheHelpers.ts:198`. ### Fixing #3 `elementCacheKeys` owns the key-variant list every cache write sets. Two of its three keys are template literals and coerce on their own; the bare-id key was passed through raw, so a non-string `elementId` reaching it put a non-string key into both maps, which prune then choked on. It now coerces that key. Review caught that it was not yet the *only* write gate: `useGsapTweenCache` built the same key list by hand at two sites, so a non-string id there still reached the maps uncoerced. Both sites now loop `elementCacheKeys`, and their matching reads use the same list instead of a second hand-rolled copy. That also closes a drift the helper's own doc comment warns about — the per-element writer omitted the `index.html#<id>` fallback key its siblings all set, so a reader falling back to that key saw a stale entry. The only remaining direct writers are in the dev-only timeline performance fixture, which generates its own string ids. The coercion **reports** the offending value's `typeof`, constructor name, and source file as `studio:cache_key_non_string` rather than swallowing it. This is deliberate: every writer that reaches `elementCacheKeys` was traced and each one produces a string, so **which caller supplies a non-string id is still unknown**. Rather than guess at a producer, this hardens the single gate that can guarantee the maps' declared contract, and makes the next occurrence name its own producer. Only the value's shape is reported, never its content. Fixes 1 and 2 are both the smaller diff *and* the root fix: one guard where every caller routes through, rather than one per call site. No behaviour change on any happy path. ## Test plan - [x] Unit tests added/updated - [ ] Manual testing performed - [ ] Documentation updated (if applicable) Six regression tests, every one verified to fail without its fix: - `Player.test.ts` — detaches the player element, then unmounts. Without the fix: `DOMException: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.` - `LeftSidebar.storage.test.ts` — makes the `localStorage` property getter throw, then calls `getPersistedTab()`. Without the fix it fails with the same `SecurityError` the crash reports carry. - `gsapKeyframeCacheHelpers.test.ts` — four cases: keys stay strings, the violation is reported, the normal string path stays silent, and a prune after a non-string write does not throw. Without the fix the last one fails with `TypeError: key.indexOf is not a function`. Full Studio suite green: 3559 passed, 335 files, 0 failures. `oxlint`, `oxfmt` and `tsc --noEmit` clean. Manual testing is unchecked deliberately: none of the three reproduces on a normal local profile, which is why they only surfaced in crash reports. The tests exercise the exact throwing boundaries instead. ## Not covered Two other crash signatures reviewed alongside these are **not** fixed here: one occurs almost entirely on locally-built dev Studio rather than released builds, and the other has not appeared on any recent release. **Follow-up worth its own PR:** ship sourcemaps for the Studio build. Rebuilding a tag to decode one frame worked, but it should not be the process, and it is the prerequisite for diagnosing the next minified crash.	2026-08-07 19:20:18 -07:00
Miguel Ángel	a850e97f3d	fix(studio): resize an element whose scale is an instant hold (#3092) ... * fix(studio): stop a resize writing size into the tween that carries scale Resizing a scale-driven element failed with "animation not found", and the element could not be saved again at all. The tween resolved for the resize's group is, for such an element, the one carrying `scale`. When it is an instant hold the code handed it straight to the size commit, which wrote `width` and `height` into it. One tween now spanned two property groups, so the parser classified it as neither — it lost its group suffix, and its id with it. Every later edit looked for a scale tween and a size tween, found a tween with no group at all, and had nothing it could address. Size goes to a size hold of its own now; the scale hold is left alone. Where the damage has already happened it is repairable: splitting the mixed tween into property groups gives back a `scale` tween and a `size` tween. * fix(studio): let the resize say whether it settled the drop point Resizing an element whose scale is an instant hold saved the new size and then snapped the element back to its authored position, every drag. Whether the caller persists the drag offset was inferred from the element's tweens: a scale-group tween meant "the resize settles its own position, hold the offset back". That is true of the scale route, which commits a scale and then measures where centre-scaling put the box. It is not true of an element whose scale is an instant hold — that has a scale-group tween and still commits width/height. So the offset was withheld, nobody wrote it, and the position tween re-asserted the authored value a frame later. The outcome carries the answer now. A resize that moved the element says so; everything else leaves the anchor to the drag, which is what already handles it. * test(studio): sweep every animated shape a resize can be handed Both faults on this branch were found one composition at a time, which is a bad way to find the third. Drives the real intercept across the cross-product of what an element's tweens can look like — scale absent, an instant hold, a real tween, longhands; size absent, a hold, a tween; position absent, a static hold, a tween; plus the 3D and rotation set a card carries and a tween that already spans two groups — and holds all 108 to the two rules that were broken: never address an animation the source does not have, and never leave a tween spanning two property groups. The server stand-in answers the way the real one does, rejecting an id it cannot find, and applies what it is told, so a run that corrupts the animation list is caught by the next mutation in the same run. * fix(studio): decide a uniform resize in pixels, not in scale A free corner drag whose two axes happened to land within 0.01 of each other was committed as one `scale` value for both, and gave back a box shorter than the one dropped — 326x213 became 326x211. The threshold was a fixed amount of scale. That is invisible on a 40px box and two pixels of height on a 408px one, and the question was never about scale: it is only ever whether using one value for both axes would move an edge. So it asks that, in pixels, against the axis the collapse would distort. Found by a geometry sweep added alongside: 120 runs over the routes a resize can take, six rotations from none to 180 degrees, and four drops from near-zero to an aspect flip, each checking the committed scale or size reproduces the RENDERED box the user dropped — and, where the resize reports it owns the drag offset, that the box lands on the drop point too. Six runs failed before this change, all of them the near-uniform shrink, at every rotation including none. Rotation was the suspect and turned out to be innocent. * refactor(studio): split the resize sweeps into named steps for the audit gate * test(studio): pin which tween a resize edits when the element has several A composition animates the same property more than once — a scale-in early, a scale-out late — and the one the user means is the one under the playhead. Editing the wrong one changes a moment they are not looking at and leaves the moment they are looking at unchanged, which reads as "the resize did nothing". Six playheads across two scale tweens, including both sides of the midpoint between them and a time past the end of both. Verified against a stubbed selection that always takes the first tween: three of the six fail. * fix(studio): only claim the drop point on the route that settles it Review caught the inverse of the fault above it. The three returns that report `ownsDragOffset` hardcoded `true`, and they are reached by the size-tween route too — a real, non-hold size tween with no scale group. That route never captures the element, so the finalize step no-ops, nothing writes the position, and the caller withholds an offset it would otherwise have forwarded. The release frame looks right because the live DOM was already settled; the persisted state reverts on the next seek. Fixed the same way the fault above it was: the finalize step reports whether it settled the drop point rather than the caller assuming from where it was called. It answers false when it is not the scale route, false when it cannot measure, and TRUE when the box is already on the point with nothing to write — forwarding an offset on top of that would move it off. The geometry sweep accepted this silently, and the reviewer said why: its live pose starts at the drop, which is where the gesture leaves it, so a route that moves nothing trivially "lands" there. Each route now declares whether it settles the drop point and the sweep holds it to that, which fails on 24 of the 120 runs with the old hardcoded `true`.	2026-08-07 14:29:05 -07:00
Miguel Ángel	d5cc1c9c62	fix(studio): keep the preview alive when the window is tight (#3091) ... Panel sizes are reconciled against the window on every resize, with the preview holding a 360x200 floor that panels yield to before it gives. Measured preview pane: 760px window 192 -> 433, 560px window 2 -> 516. Windows at or above 1280px are unchanged. - fitPanels owns the who-yields decision for both axes - panel caps are window-relative, replacing a flat 600px inspector cap - below 860 the sidebar rails, below 700 the inspector collapses too - auto-collapse is derived render state and never writes leftCollapsed (localStorage) or rightCollapsed (synced into the shareable URL) - the rail and header toggles act on the effective state, so neither is a dead click that silently persists a collapse the user never asked for	2026-08-07 13:35:39 -07:00
Miguel Ángel	12e637fb25	fix(studio): cover legacy resize boxes	2026-08-07 00:31:27 +00:00
Miguel Angel Simon Sierra	a693b12cca	fix(studio): correct against the scale the resize actually commits ... A near-uniform drag collapses to the `scale` shorthand, but the finalize step measured the element at the per-axis pair it computed rather than the single value the commit writes. The element was measured at a scaleY the file never gets, so the position correction came out tilted by the difference. Adds a sweep over the shapes a composition produces — shrink, grow, first resize, rotated, steeply rotated, non-uniform, near-zero, inline-sized, no position write, animated position, and two drags in a row — each checking the element renders on its drop point from the PERSISTED scale and position. The geometry model is calibrated against real gesture traces: the same inputs reproduce the rects the browser reported to three decimals.	2026-08-06 17:21:51 -07:00
Miguel Angel Simon Sierra	ee5ae9619c	fix(studio): measure the resize correction from the pre-gesture position ... A scale resize measured its drop-point correction while the gesture's own translation was still applied, but the position commit adds that correction onto the element's PRE-gesture position, which it reads from the gesture's base attributes. The two disagreed by the whole drag distance, so the commit persisted a position a drag-length from where the element was dropped: it held the drop point for one frame and then slid off. Move the element back to that base before measuring, so the residual and the commit share one origin. For an element whose position is a static hold that usually means no correction at all, which is the right answer: scaling about the centre already leaves it on the drop point.	2026-08-06 17:05:37 -07:00
Miguel Angel Simon Sierra	b18fd62e0e	fix(studio): keep an animated element on the drop point when resized ... An element whose position is animated left the drop point anyway. The finalize step wrote its correction as a static position hold, and the element's position tween rendered its own value a frame later and won. Before that it stood down entirely on such elements, on the grounds that a keyframed path has no single anchor to preserve, which had the same visible result: the element moved. It has an anchor, the frame the user is looking at. The correction now goes into that tween at the playhead, through commitGsapPositionFromDrag, which is the same commit a drag on the same element already uses. Static holds keep the existing path. This is the difference the debug log showed between an element carrying position:to, which moved after release, and one carrying position:set, which did not.	2026-08-06 17:02:14 -07:00
Miguel Angel Simon Sierra	7dc18771d1	fix(studio): pin the drop point on a first resize ... The finalize step measures where the committed scale put the box and shifts the position hold by the difference. Whether the commit had actually rendered when it measured was luck: on a first resize the timeline had not re-seeked, so it measured the element at its natural size still sitting on the drop point, saw no residual, and skipped the correction. The scale then landed, GSAP rendered it about the element's centre, and the element jumped by the whole drag distance. Elements resized before got a correction only because their previous scale made the residual non-zero by accident. The committed scale is now applied to the live element before measuring, so the measurement means what its comment says either way, and a skipped correction is logged rather than silent. Confirmed against a real session: a first resize of a 630px chip now reports residual -109.93 and lands on the drop point, where it previously logged no scale-finalize at all.	2026-08-06 17:02:14 -07:00
Miguel Angel Simon Sierra	20ef798620	fix(studio): stop a uniform resize writing a scale GSAP ignores ... A uniform drag committed the `scale` shorthand. If the tween's keyframes already stated `scaleX` and `scaleY`, the commit left both forms in the same keyframe, and GSAP animates each property name independently, so the longhands ran alongside the shorthand and won. The resize therefore computed the right number, wrote it to the file, and did nothing: the element snapped back to its old size the moment the handle was released. Reproduced from a real session, where a drop at 384px on a 630px element wrote {scaleX: 1, scaleY: 1, scale: 0.61} and rendered at the original size. The mixing hazard was already known in the other direction, where a non-uniform drag takes a rewrite path that normalizes every keyframe to the longhands. This makes the condition symmetric: whenever the tween already speaks longhands, a uniform drag speaks them too.	2026-08-06 16:18:13 -07:00
Miguel Angel Simon Sierra	477f77629b	fix(studio): resize from the element's real box, not a 200px guess ... Resizing an element whose size is driven by a scale animation committed a scale computed against a hardcoded 200px fallback, because the only original size the draft recorded was the element's INLINE width, and a composition sizes its elements from the stylesheet. A 630px chip dropped at 1260px wide committed a scale of 6.3 instead of 2, so it landed at over three times the size it was dropped at. The next drag compounded it, because that wrong scale then counted as the element's live one. The draft now records the box it measured, once, before it writes a width of its own, and the intercept reads that. The inline attributes keep their own job of restoring an inline style, which is why they cannot answer this question.	2026-08-06 15:53:36 -07:00
Miguel Ángel	88853f170f	fix(studio): route rooted timeline media through preview (#3061)	2026-08-05 22:14:28 -07:00
Miguel ÁngelandCodex	96861cbafc	perf(studio-server): coordinate cancelable thumbnail generation (#2720) ... * perf(studio): schedule adaptive timeline thumbnails * perf(studio): bound thumbnail decoding resources * perf(studio): virtualize timeline thumbnail media * perf(studio): prioritize timeline thumbnail work * perf(studio-server): coordinate cancelable thumbnail generation --------- Co-authored-by: Codex <codex@local>	2026-08-05 20:41:35 -07:00
Miguel Ángel	bce2140ff2	test(studio): relax large fixture timeout (#3040)	2026-08-04 18:58:24 -07:00
Miguel Ángel	7bf425b7a9	docs(studio): document timeline keyboard navigation (#3031) ... * feat(studio): expose timeline treegrid semantics * feat(studio): coordinate logical timeline focus * feat(studio): add timeline keyboard controls * docs(studio): document timeline keyboard navigation	2026-08-04 17:09:07 -07:00
Miguel Ángel	ebdd1893c4	fix(studio): reconcile external edits before reload (#2993) ... * fix(studio): reconcile external edits before reload * fix(ci): retry transient workspace installs Make external reload retry behavior honest and isolate reload listeners. Remove the dead SDK timestamp parameter.	2026-08-04 23:13:19 +00:00
Miguel Ángel	a99caad581	feat(studio): coordinate external file changes (#2991)	2026-08-04 22:20:44 +00:00
Miguel Ángel	b30a23402e	feat(studio): preserve external file conflicts (#2990) ... * fix(studio): drain pending edits before reload * fix(studio): address drain review feedback (#2989) - prioritize conflicts and clear recovered DOM queue errors - cover delayed blur effects and missing drain branches - document stacked consumers and extend write-token retention * test(studio): satisfy drain audit gate (#2989) - share the editor-save hook harness across drain regressions - extract settled failure inspection from the drain loop * feat(studio): preserve external file conflicts * fix(studio): isolate retry write receipts * test(studio): cover external conflict recovery safety	2026-08-04 21:19:42 +00:00
Miguel Ángel	4713138544	fix(studio): drain pending edits before reload (#2989) ... * fix(studio): drain pending edits before reload * fix(studio): address drain review feedback (#2989) - prioritize conflicts and clear recovered DOM queue errors - cover delayed blur effects and missing drain branches - document stacked consumers and extend write-token retention * test(studio): satisfy drain audit gate (#2989) - share the editor-save hook harness across drain regressions - extract settled failure inspection from the drain loop	2026-08-04 20:58:19 +00:00
Miguel Ángel	552419c52d	fix(studio): make inspector commits transactional (#2987) ... * fix(studio): make inspector commits transactional * fix(studio): make inspector persistence atomic * fix(studio): preserve synchronous gesture semantics	2026-08-04 20:26:43 +00:00
Miguel Ángel	cde5bae4c5	test(studio): pin text-field Backspace routing (#2988)	2026-08-04 13:23:25 -07:00
Miguel Ángel	cf45c98454	fix(studio): respect GSAP transform ownership (#2986) ... * fix(studio): respect GSAP transform ownership * fix(studio): enforce GSAP edit ownership consistently	2026-08-04 19:08:02 +00:00
Miguel Ángel	0a70ba6717	fix(studio): scope timeline ease focus lifecycle (#2710)	2026-08-03 23:06:46 -07:00
Miguel Ángel	423c5ffadb	fix(studio): scope timeline context targets (#2708)	2026-08-03 21:19:49 -07:00
Miguel Ángel	c6925e471a	feat(studio): enable timeline virtualization by default (#2926) ... * feat(studio): enable timeline virtualization by default * fix(ci): measure timeline performance in production React	2026-07-31 19:43:47 +02:00
Miguel Ángel	723d3381c4	fix(studio): keep dense keyframes readable (#2925) ... * perf(studio): define timeline viewport budgets and fixtures * test(studio): gate timeline viewport performance in Chromium * refactor(studio): isolate clip drag lifecycle * refactor(studio): extract timeline render contracts * perf(studio): centralize timeline viewport geometry * perf(studio): follow playhead across virtualized rows * perf(studio): add timeline clip-window index primitive * perf(studio): virtualize timeline clip windows * perf(studio): stop timeline scroll work when row virtualization is off The row virtualization stack made the timeline publish a viewport snapshot on every scroll frame and swap `renderClipContent` across every mounted clip at gesture start and settle. Both are windowing concessions, and neither was gated on the flag, so the build users actually run paid for them while mounting all 1,000 clips anyway. Measured on a 3,000-clip project: median scroll step 16.6ms to 76.9ms, p95 17.9ms to 189.4ms, 40 long tasks to 247. Gate both on the row virtualization flag. The scroll path now stops at the door when the flag is off, so `isScrolling` stays false and resize-driven and programmatic syncs still publish through the immediate path. The flag moves into its own module: the scroll-viewport hook needs to read it, and the virtualization hook already imports the viewport snapshot type back, which would have closed an import cycle. Also release the perf fixture lease from the fixture rather than from the test-hook effect. Loading a fixture writes player state, which changed that effect's dependency identities and tore it down on the next frame, so the lease was revoked moments after it was taken and live iframe discovery overwrote the fixture before the gate could measure it. The e2e gate gains a flag-off arm (`test:timeline-default`, 1,000 elements) next to the existing flag-on one. It refuses the 50,000-element combination, verifies from the mounted DOM that the server under test matches the requested flag, and skips the DOM-size budgets for the unvirtualized build rather than relaxing them, so a skipped budget never reads as a passed one. Verified against a live Studio dev server on the fixture project: flag off, before: interactionP95 303.1ms, longest task 194ms, 0/5 runs pass flag off, after: interactionP95 33.6ms, longest task 0ms, 5/5 runs pass flag on, after: interactionP95 33.2ms, 4/5 runs pass, exit 0 The flag-on arm's fourth run reproducibly reports a 55-58ms long task against a 50ms budget. That is the residual tail of the window swap itself, tracked separately and not addressed here. * ci(studio): run the timeline viewport gate on studio changes The gate has existed since the row virtualization stack landed but nothing under `.github/` referenced it, so it only ever ran when someone ran it by hand. That is how the flag-off scroll regression reached eight merged-ready PRs without anything noticing. Adds a `studio-timeline-viewport` job that boots two Studio dev servers, one per flag state, and runs both arms of the gate against them. Two servers are needed because row virtualization is read from `import.meta.env` at module load, so one process cannot serve both builds. Scoped to a new `studio` paths filter rather than the broad `code` one: the gate only says anything about `packages/studio`, `packages/core` and `packages/studio-server`. Adds a `ci` tier. It applies the constrained budgets without any emulation, because a hosted runner is already slower and noisier than the machine the strict numbers were recorded on, while the existing `low-resource` tier would throttle it a further 4x and measure the throttle rather than the build. The fixture composition is tracked under `tests/e2e/fixtures` but Studio resolves projects from the gitignored `data/projects`, so the job copies it into place instead of a project directory being committed. Both arms run in about 7 seconds each locally, so the job cost is almost entirely dependency install and the workspace build it shares with `studio-load-smoke`. * fix(ci): preserve both timeline gate evidence arms * ci(studio): report timeline gate arm statuses * ci(studio): require timeline gate evidence artifacts * fix(studio): keep dense keyframes readable * fix(ci): resolve timeline stack audit findings	2026-07-31 18:05:22 +02:00
Miguel Ángel	fbfffb1aa7	fix(studio): release retained preview resources (#2924)	2026-07-31 14:31:43 +02:00
Miguel Ángel	cef3b86c95	chore(studio): remove fully rolled-out studio feature flags (#2889) ... ## What Removes six Studio feature flags that have been default-`true` for 7+ weeks. Each is reachable under two env names, so this deletes **12 `VITE_STUDIO_*` env vars**: | Flag constant | Env names removed | Default-on since | |---|---|---| | `STUDIO_PREVIEW_MANUAL_EDITING_ENABLED` | `VITE_STUDIO_ENABLE_PREVIEW_MANUAL_DRAGGING`, `VITE_STUDIO_PREVIEW_MANUAL_EDITING_ENABLED` | 2026-05-12 | | `STUDIO_INSPECTOR_PANELS_ENABLED` (+ its `STUDIO_PREVIEW_SELECTION_ENABLED` alias) | `VITE_STUDIO_ENABLE_INSPECTOR_PANELS`, `VITE_STUDIO_INSPECTOR_PANELS_ENABLED` | 2026-05-12 | | `STUDIO_BLOCKS_PANEL_ENABLED` | `VITE_STUDIO_ENABLE_BLOCKS_PANEL`, `VITE_STUDIO_BLOCKS_PANEL_ENABLED` | 2026-05-18 | | `STUDIO_GSAP_PANEL_ENABLED` | `VITE_STUDIO_ENABLE_GSAP_PANEL`, `VITE_STUDIO_GSAP_PANEL_ENABLED` | 2026-05-28 | | `STUDIO_KEYFRAMES_ENABLED` | `VITE_STUDIO_ENABLE_KEYFRAMES`, `VITE_STUDIO_KEYFRAMES_ENABLED` | 2026-06-05 | | `STUDIO_RAZOR_TOOL_ENABLED` | `VITE_STUDIO_ENABLE_RAZOR_TOOL`, `VITE_STUDIO_RAZOR_TOOL_ENABLED` | 2026-06-10 | ## Why Every one of these shipped as a rollout gate, went to `true`, and then stayed. Because none of them was ever flipped back, the `false` branch was unreachable in practice while still costing a real import, a real conditional, and a real "what happens if this is off?" question at ~90 call sites across 25 files. The bigger cost is what the dead branch kept alive. Removing the flags also removes the disabled-Studio code paths that only existed to serve them: - the greyed-out, `disabled`, "Manual editing is temporarily disabled" Inspector button in `StudioHeader` (and the `STUDIO_MANUAL_EDITING_DISABLED_TITLE` constant behind it) - the inspector-off reset `useEffect` in `useDomSelection`, which force-cleared selection and redirected the right panel to Renders - three selection kill-switch early-returns in `useDomSelection` (`applyDomSelection`, `handleTimelineElementSelect`, `applyMarqueeSelection`) - the tab-redirect branch in `normalizeStudioUrlPanelTab`, whose `options.inspectorPanelsEnabled` parameter had no production caller at all (only tests passed it) ## How No behavior change: every flag was removed by keeping its default-`true` side. The call-site edits are three mechanical boolean shapes (`X && rest` → `rest`, `rest && X` → `rest`, `!X || rest` → `rest`), applied by script for uniformity. Everything else (ternaries, `if` guards, unreachable blocks, JSX wrappers that had no other condition) was done by hand and the whole diff was read line by line afterwards. `resolveStudioBooleanEnvFlag` and the `import.meta.env` / `window.__HF_STUDIO_ENV__` plumbing stay: three flags still use them (`STUDIO_FLAT_INSPECTOR_ENABLED`, `STUDIO_SDK_CUTOVER_ENABLED`, `STUDIO_SDK_RESOLVER_SHADOW_ENABLED`). Its unit tests kept their coverage but now exercise a live flag pair instead of retired env names, so no dead `VITE_STUDIO_*` string is left in the repo. Net **-191 lines** (236 insertions, 427 deletions across 25 files); most insertions are reindentation of JSX that lost a wrapper. ### Deliberately not in scope Flags authored by other people are untouched, even where they look similarly settled: - `VITE_STUDIO_ENABLE_FLAT_INSPECTOR` / `VITE_STUDIO_FLAT_INSPECTOR_ENABLED` (default true, but not mine) - `VITE_STUDIO_SDK_CUTOVER_ENABLED`, `VITE_STUDIO_SDK_CUTOVER_FAMILIES`, `VITE_STUDIO_SDK_RESOLVER_SHADOW_ENABLED` (SDK cutover canary, still soaking) - `VITE_HYPERFRAMES_NO_TELEMETRY` Mine but genuinely long-lived configuration rather than rollout gates, so they stay: `VITE_STUDIO_DISCOVERY_PORTS`, `VITE_HYPERFRAMES_FEEDBACK_INTERVAL`, `VITE_HYPERFRAMES_NO_FEEDBACK` (a documented user opt-out), plus the `HYPERFRAMES_*` binary paths, API URLs, cache sizes, and timeouts. `VITE_STUDIO_ENABLE_MOTION_PANEL` / `VITE_STUDIO_MOTION_PANEL_ENABLED` were already retired from production code before this PR; they only survived as placeholder names inside the resolver's unit tests, and this PR swaps those out. ## Test plan - [x] Unit tests added/updated - dropped the two tests asserting removed flag defaults; retargeted the `resolveStudioBooleanEnvFlag` cases at a live flag pair; updated `studioUrlState` tests for the narrowed `normalizeStudioUrlPanelTab` signature (now also asserts an unknown tab returns `null`). - [x] Manual testing performed - see below. - [ ] Documentation updated (if applicable) - not needed; no removed name appears in `docs/`, `skills/`, or `registry/`. (`docs/changelog.mdx` has one historical entry naming `STUDIO_KEYFRAMES_ENABLED`; changelog history is left as written.) ``` packages/studio: bunx vitest run # 280 files, 3116 tests pass, 1 skipped packages/studio: bunx tsc --noEmit # clean bun run build # green (all packages) bunx oxlint <25 changed files> # 0 warnings, 0 errors bunx oxfmt --check <25 changed files> # clean ``` Two extra checks, because part of this diff was script-generated: 1. Zero references to any removed flag constant or env name remain anywhere outside `docs/changelog.mdx`. 2. Diffed every string literal in each changed non-test file against `origin/main`. The only differences are the intended removals: the 12 env names, `"Manual editing is temporarily disabled"`, the `"cursor-not-allowed …"` disabled class, the 3-column `"1fr 1fr 1fr"` grid, and the `"renders"` redirect literals. No user-facing label, tooltip, or class string changed by accident.	2026-07-30 02:00:05 +02:00
Miguel Angel Simon Sierra	6b11d37433	fix(studio): publish keyframe cache refresh atomically	2026-07-29 03:44:30 +02:00
Miguel Angel Simon Sierra	23ab104aff	refactor(studio): split bulk easing helpers	2026-07-29 03:39:52 +02:00
Miguel Angel Simon Sierra	10d45def05	feat(studio): bulk-edit easing for merged keyframes	2026-07-29 03:39:51 +02:00
Miguel Ángel	7482c22d82	fix(studio): target colliding keyframes exactly (#2692)	2026-07-29 03:39:17 +02:00
Miguel Angel Simon Sierra	1f3fd2800c	fix(studio): give the motion path and the fallbacks a one-element target ... The narrowing this branch adds missed the motion-path overlay, and every caller that could not narrow fell back to the exact bare class the narrowing exists to replace. - motionPathSelection.selectorFor now goes through writeTargetSelector. It feeds both the geometry read and the "set destination" write, so a class sibling measured its home off the FIRST sibling and then authored add-motion-path onto all of them. The toolbar toggle hides when no one-element form exists rather than arming a press that is dropped. - The five new-tween writers that fell back to the selection's own selector now drop the commit instead. A gesture that does not persist reverts on the next reload; a tween silently aimed at five elements does not. - tweenTargetsElement only follows the DOM to a target that matches exactly one element. A target the element merely shares with its siblings is a group tween, and these callers mutate what they find, so an individual nudge was rewriting the group's own tween and moving all five.	2026-07-28 21:21:37 +02:00
Miguel Angel Simon Sierra	3d92436066	fix(studio): author every new tween against one element ... U3 fixed "add keyframe at playhead" widening a write to every sibling sharing a class, but wired writeTargetSelector into only two paths. The same bug was still reachable from the add-animation button, drag, resize, rotate, gesture recording, and the property panel: each derived its target from selectorFromSelection, which hands back a bare class for an id-less element, so one edit authored a tween over all five siblings and the timeline collapsed their rows into one. Route every path that authors a NEW tween through the existing ladder: - ensureElementAddressable now accepts selection.selector only when it addresses exactly one element, so the id-minting fallback right below it (previously unreachable whenever any selector was present) does the work. - gsapDragCommit's five new-tween branches go through one newTweenTarget helper; instant patches reuse the written target so the runtime moves the element the source write names. - useGestureCommit and useAnimatedPropertyCommit keep the existing selector for matching/retargeting and author new tweens with a separate write selector. Retargets of an EXISTING tween are deliberately untouched: they keep anim.targetSelector, so a tween aimed at a whole group stays aimed at it. Narrowing the write alone regressed idempotency, verified by test: the "is there already a write for this element" lookups matched targetSelector by string, so the next nudge missed the write it had just made and appended a second, conflicting one. The read half now falls back to the live DOM (tweenTargetsElement, same contract as getAnimationsForElement), which also still matches a deliberate group tween. Tests reproduce each site through a real writer, re-parse with the real parser, and resolve through resolveSelectorElementIds (what feeds the keyframe cache and the lanes), plus pins for the new-tween vs retarget-existing distinction so a future change cannot collapse the two.	2026-07-28 21:21:37 +02:00
Miguel Angel Simon Sierra	ba0d6406d2	fix(studio): scope lane ids per timeline and stop inventing a track row ... Two latent defects in the announcement path this branch adds. - lanesId was keyed by render row alone, so a second TimelineLanes on the page (a mini-timeline beside the main one) would mint the same timeline-lanes-track-0 and every caret's aria-controls would resolve to whichever instance mounted first. The prefix now comes from useId, with the colons stripped so the id stays a legal CSS selector. - trackDisplayNumber returned trackOrder.length + 1 for a key it could not find, which is indistinguishable from a real row: the label announced a row the user can see is wrong and nothing upstream could tell it had guessed. It returns null now, and trackDisplaySuffix drops the number from the label rather than inventing one.	2026-07-28 21:21:27 +02:00
Miguel Angel Simon Sierra	477916cbe2	fix(studio): label undo history with the track display row ... The timeline track key is a fractional z-order sort key: an expanded sub-composition child gets `host.track + n / (siblings + 2)`. The undo history entry for the eye toggle interpolated that key directly, so hiding an expanded child recorded "Hide track 0.16666666666666666". Give the key-to-display-row conversion a single owner (timelineTrackDisplay.ts) and route both the track header labels and the history label through it, so the two cannot drift apart again. The raw key still routes the callbacks and lookups that need it. Adds a regression test that toggles a track keyed 1 / 6; a test on track 0 formats cleanly and proves nothing.	2026-07-28 20:37:52 +02:00
Miguel Angel Simon Sierra	f04cdb79c5	fix(studio): never re-author a target the DOM proved is not unique ... writeTargetSelector returned the selection's bare selector whenever the structural walk failed, including when a live DOM was there to check against. An element detached between selecting and committing takes that path, so the add re-authored the exact `.group` string the function exists to replace. Return null instead: a failed walk against a live DOM is evidence, not absence of it. Callers that cannot drop a user edit opt back in with `?? selectorFromSelection` where the trade is visible. The replace-with-keyframes paths had the mirror defect. The server deletes and re-adds the tween, so their target string is a full rewrite, and they derived it from the selection: promoting a set on a tween already narrowed to `#scene > div:nth-child(3)` widened it back onto every class sibling, undoing the narrowing an earlier add had made. They now keep the tween's own authored target, matching what eight sibling commit modules already do.	2026-07-28 20:37:52 +02:00
Miguel Angel Simon Sierra	fd5555be75	fix(studio): target one element when adding a keyframe at the playhead ... "Add keyframe at playhead" on an element with no id authored the bare class buildStableSelector hands back, so one add on a `.group` wrote `tl.to(".group", ...)`: a tween that animates all five siblings and that resolveSelectorElementIds reads back as all five, collapsing their timeline rows into one. It survived a reload, so the written file stayed un-editable. writeTargetSelector is the write-side counterpart to selectorFromSelection (which must keep returning the exact string findTweenAtTime compares against). It resolves the element's own identity to a selector that addresses exactly one element: `#id`, else `[data-hf-id="..."]`, else the selection's selector when it is already unique, else a `:nth-child` path anchored on the nearest identifiable ancestor (the selector + selectorIndex pair, resolved through the DOM the index was counted in). Applied to the two paths that author a NEW tween: the no-animation branch of useEnableKeyframes and commitKeyframeAtTimeImpl. replace-with-keyframes still writes the selection's own selector, since retargeting a tween the author aimed at a whole group is a different decision from adding a keyframe.	2026-07-28 20:37:52 +02:00
Miguel Angel Simon Sierra	59a818e80a	fix(studio): lane every tween and attribute tweens to their real target ... Two halves of one inversion in the expanded timeline lanes: the tweens that should show were filtered out, and a tween that should not be there was the only survivor. Lane classification read the parser's whole-tween verdict, which is undefined for anything spanning more than one property group. `{x, opacity}` is the canonical HyperFrames entrance tween, so five of the seven tweens in the swiss-grid graphics example had no caret, no reserved row and no diamonds. Classify per property instead, through one helper both the rendered lanes and the reserved row heights count through so they cannot drift again. Attribution matched an unanchored leading id, so `#stat3 .block` was filed under `#stat3`. The child's diamonds landed on its ancestor and collided with the ancestor's own tween at the shared percentage, which the same-percentage merge then resolved by dropping the ease. Route attribution through resolveSelectorElementIds, which anchors a whole-selector id and otherwise resolves through the live preview DOM, and anchor its no-DOM fallback so a descendant selector resolves to nothing rather than to its ancestor. The merge rule is unchanged. Also brings the last property-lane call site onto the shared clip timing basis: an expanded sub-composition child's start is host-absolute while its tweens are local to its own file.	2026-07-28 19:02:25 +02:00
Miguel Angel Simon Sierra	acad7b268e	fix(studio): keep every host row on the drill path, not just the top ... Drilling two levels deep spared only the top-level row, so the middle host lost its row and its keyframe lane with it. Spare every host between the drilled one and the top, and anchor the children under the deepest host that actually has a row. Also stops resolveClipTimingBasis handing back a main-timeline start when a clip names a parent composition that is absent from the element list. The mount is unknowable there, so the child's own window is the only safe frame.	2026-07-28 19:02:05 +02:00
Miguel Angel Simon Sierra	3f0c20f633	fix(studio): compute keyframe percentages in the tween's own time frame ... A sub-composition tween's resolvedStart is composition-local, while the timeline element resolved for it is the sub-comp HOST, whose start is main-timeline absolute. toClipPercentage subtracted the two frames from each other, so a host mounted at 1.5s cached its 0s tween at -12% and its last tween's end keyframe at 88% instead of 100%. A clip-relative percentage can never be negative. resolveClipTimingBasis now returns the clip start in the frame the tween's own times are measured in: the composition mount (expandedParentStart for an expanded child, the parent composition clip's start otherwise, 0 for a root-composition element) is subtracted, and a sub-comp inner element that falls back to its host's window starts at 0 in that window. It moves to gsapShared so the post-commit cache writer can share it instead of resolving its own basis, which also gives that writer the sub-comp host fallback it was missing.	2026-07-28 18:04:37 +02:00
Miguel Angel Simon Sierra	8470b88aa1	fix(studio): settle boundary retimes, delete every keyframed tween, tighten the test locks ... Review follow-ups on the expanded keyframe lanes. Writer: - `onMoveKeyframe`'s flat-tween boundary branch answered `true` the moment it dispatched update-meta, so a rejected write left the diamond parked at its drop position. `observeGsapMutation` now resolves to whether the mutation landed and the boundary branch returns it, matching the other branches. - "Delete All Keyframes" cleared only the first keyframed tween on the layer, so a layer with position AND opacity keyframes kept half of them. It now walks every keyframed tween, serially, through the clicked element's selection. - The post-convert lookup in `commitFlatViaKeyframes` matched by target selector, which picks an arbitrary tween when a target carries several. Match by id first. Interaction and a11y: - A rejected retime whose commit settled after a newer drag reverted the selection to its own source keyframe, undoing a retime the user could see. The revert now only runs while it is still the lane's latest gesture. - Diamonds key on the authored identity instead of index plus rendered clip-%, so a neighbour's retime no longer remounts the button mid-drag. - The disclosure caret gets `aria-controls` on an always-mounted lanes container, and both it and the property-group toggle grow to the 24x24 WCAG 2.2 minimum. - `LayerDisclosureRow` takes the same adaptive `columnWidth` as its sibling lane rows instead of hardcoding LABEL_COL_W over the canvas. Test locks: - The timeline callbacks harness resolves a DISTINCT selection per element, so the clicked-element writes are actually pinned; three assertions that passed either way now name the clicked element's selection. - New: null-selection aborts every mutation, delete-all covers both tweens, a rejected boundary retime reports `false`, and a stale revert leaves selection. - The playhead-percentage assertion checks 25, not `expect.any(Number)` (which also accepts NaN); ease segments assert their label ORDER, not just that the three curves differ; the collapsed-diamond callback asserts the whole target. - Dropped a duplicate `selection override` describe left by a rebase.	2026-07-28 01:19:05 +02:00
Miguel Angel Simon Sierra	c20c5366da	fix(studio): commit lane edits through the edited element's own selection ... An explicit null selection override now aborts the write instead of falling back to domEditSelection: a caller that resolved a selection for its own element and found none was committing onto whichever element happened to be selected. Ease changes and the playhead keyframe toggle resolve the edited element's animations and selection instead of the current selection's, and lane header rows follow the real label-column width so a narrowed column no longer hangs its value readout over the canvas.	2026-07-28 00:40:47 +02:00
Miguel Angel Simon Sierra	e317f1fbe3	refactor(studio): double-cast test fixtures and split three dense functions ... CONTRIBUTING.md allows `as unknown as T` with a justification, not a bare `as T`; the gsapShared fixtures only carry the fields under test. The fallow complexity gate flagged three functions on this branch. Each is split at its natural seam rather than suppressed: the auto-expand scan moves out of the effect, the four repeated attribute guards in nodeMatchesManifestClip collapse into one table-driven check, and the segment-% interpolation moves out of onPathDown.	2026-07-28 00:40:46 +02:00
Miguel Angel Simon Sierra	b8ff8bf0f3	fix(studio): close the review findings that survived the stack ... Selector reads now go through one inverse of `idSelector`. Every writer emits `[id="01-hook-hero"]` for an id a `#id` selector can't address, but the readers still matched `#id` only, so the post-commit keyframe-cache refresh, the AST load and the remove-all-keyframes clear all silently skipped exactly the ids `idSelector` was added to support. A keyframe merged from two tweens with different eases kept whichever ease iterated last. Readers that don't check `easeAmbiguous` showed a curve from a different animation than an edit would target, so the ambiguous flag now clears `ease` instead of leaving an arbitrary one behind. One tolerance for "the playhead is on this keyframe". The motion-path drag used 0.05% while the toolbar and the playhead apply used 1%, so a drag that landed a fraction of a percent off an authored waypoint skipped the update-point branch and appended a near-duplicate. `buildTemporalArcKeyframes` now owns the invariant and replaces any keyframe inside the tolerance, rather than trusting each caller's own pre-check. The pending-retime bookkeeping matches on keyframe identity, not just on "something is near that percentage" — an evenly spaced row cleared the entry off an unrelated sibling. The neighbour clamp composes pending destinations in before sorting, so a second drag can't cross a neighbour that already moved. Also: `keyframeCache`/`gsapAnimations` setters return the same state for a write that changes nothing (every no-op re-rendered every subscriber), the auto-expand set drops clips that left the source so an undo/paste under the same id expands again, `invalidateGsapCache` has a stable identity instead of re-creating the whole timeline edit context each render, the studio test hook deletes its window key rather than leaving it enumerable as undefined, and the past-last-row extrapolation documents why it uses TRACK_H where the pre-first-row branch uses row 0's own height. Covers `idFromSelector` round-trips, the insert boundary band across plain, expanded and unusable row heights, and the collapsed selection key for a colon-bearing element id.	2026-07-28 00:40:46 +02:00
Miguel Angel Simon Sierra	8b38a8562e	fix(studio): close the timeline regressions the QA triage attributed here ... The QA fleet's 295 findings were replayed against the merge-base. Most were pre-existing, but these were caused by this stack: Deleting one keyframe destroyed the whole tween. The lane-header remove toggle escalated a flat tween to a whole-animation delete, which took the authored `tl.to(...)` and its source comment with it on a single click. The base build posts remove-keyframe and lets the writer refuse it; restore that. A keyframed layer could not be hidden at all. The visibility eye had moved off the always-mounted layer row onto a hover-gated property-group row, so it only existed while the lanes were expanded AND the pointer was over that lane. A keyboard-only user could reach no eye at all, and its label named a track its row did not act on. It goes back on the layer row. A drag from the centre of a clip bar did nothing, because the 16px inline ease button sits exactly there and swallowed the press. It now lets the press through to the clip and keeps only the click, dropped if the pointer travelled. Dragging a diamond onto a neighbour silently discarded the retime. The clamp bounded the dragged keyframe by the whole merged row, so two animations colliding at one percentage pinned each other in place and the drag resolved back to a click. Clamp against the dragged keyframe's own tween instead. Also: floor the diamond hit box at 12px (the gap-derived size fell to ~7px at the zoom floor), round the diamond tooltip percentage, and prune the keyframe caches when a composition switch drops a file from the scan set — each file only ever cleared its own entries, so the previous composition leaked every element into both keyframeCache and gsapAnimations, with nothing to evict it.	2026-07-28 00:40:45 +02:00