feat(studio): alt marquee removes the covered items from the selection - #5680

Code verdict: approve-ready. I found no blocking issues. The one open question is whether Alt is the modifier we want, which is a product call, so I'm leaving the merge decision to the maintainers. Two small suggestions are below. Neither one blocks.

What I checked

• utils/marqueeGeometry.ts:28: resolveMarqueeMode is now the only place that reads the modifiers, and Alt wins over Shift as the PR says. On the timeline, the mode set at pointerdown (Cmd/Ctrl gives add) is still the base, and Shift or Alt held mid-drag overrides it (useTimelineRangeSelection.ts:218, :350). That matches how Shift already behaved. The edge auto-scroll path now carries Alt too, through MarqueePointer.
• Canvas subtract (hooks/useDomSelection.ts:506): it filters the seeded group, clears the selection when nothing is left, and re-anchors the primary on the first survivor. With no hits, the selections.length === 0 early return keeps the selection unchanged. That is correct, and it now also covers subtract because it tests replace rather than !additive.
• Timeline subtract (timelineMarquee.ts:129, useTimelineRangeSelection.ts:111): hits are deleted from the pre-drag base, survivingPrimary keeps the old primary when it is still selected, and Escape still restores the snapshot.
• Every in-repo caller of applyMarqueeSelection and onMarqueeSelect was moved from false to "replace" (useStudioUrlState.ts, useTimelineSelectionPreviewSync.ts, marqueeCommit.ts). I grepped and found none left on a boolean.
• I checked Alt's existing meanings in Studio. Alt+click jumps to source and Alt+drag turns off snapping, but both apply only when the press lands on an element. A marquee only starts on empty canvas (DomEditOverlay.tsx, the fresh hit-test before marquee.begin), so the two don't collide.

What I ran

• vitest on the 9 touched suites: 142/142 pass. tsc --noEmit for packages/studio is clean.
• Mutation check: I disabled the subtract branch in computeMarqueeSelection and the filter in applyMarqueeSelection. That made 9 tests fail across timelineMarquee, useTimelineRangeSelection and useDomSelection, so the new tests do catch the behavior.

Suggestions (non-blocking)

1. Canvas candidate outlines while subtracting. MarqueeOverlay.tsx:16-29 turns every element the band touches red, including elements that aren't selected and that the release will leave alone. On the timeline the live selection itself shows what will happen, but on the canvas the red outlines suggest that more will be removed than really is. You could filter candidateRects down to members of the current group in subtract mode, or keep unselected candidates in the neutral style.
2. Hosts that consume useMarqueeGestures and ignore the second argument. The API note covers the type change. One thing it doesn't cover: a host that reuses MarqueeOverlay with this hook but decides add/replace on its own will now draw the red "remove" band under Alt, yet still commit a replace or add. That's worth noting in the release notes, so those hosts can either handle mode or keep Alt out of the band.

Thanks for the careful scoping and the thorough tests.

— Rames

Thanks for the careful work here. resolveMarqueeMode as the single place that reads the modifiers is a nice shape, and the timeline tests drive the real pointer handlers, so they cover what people will actually do. I agree with the earlier review's two suggestions and won't repeat them. A few additions:

1. Alt pressed at the start of a drag behaves differently on the two surfaces. On the timeline, the mode resolved at pointerdown becomes the base (useTimelineRangeSelection.ts:350, then :218 falls back to it), so if you press Alt, start dragging and then let go of Alt, the marquee keeps subtracting. On the canvas the mode is re-read from each move and from the release event (marqueeCommit.ts:283, :305), so the same gesture ends as a replace, and the selection becomes exactly the items you meant to remove. Either rule is reasonable, but it would be good for both surfaces to follow the same one, with a test that releases the modifier mid-drag to pin it.
2. Rebase needed. useDomSelectionTypes.ts now conflicts with a change on main that added an iframe parameter to refreshDomEditSelectionFromPreview and removed refreshDomEditGroupSelectionsFromPreview. It's an adjacent-line conflict: keep both of main's changes plus your new mode signature. Everything else merges cleanly, and I found no caller added on main since your base that still passes a boolean.
3. CI hasn't run on this head yet, so a maintainer will need to start the workflows after the rebase.

None of this blocks on the code itself. I'm leaving a comment rather than an approval because of the conflict and the missing CI run.

Verdict: COMMENT
Reasoning: The code looks correct and well tested, but the branch conflicts with main and no CI has run at this head; one small cross-surface inconsistency is worth settling first.

Thanks for the rebase and for addressing both earlier rounds. I ran it for real at this head and the behavior is right, so I'm approving and turning on auto-merge.

What I verified

• Alt released mid-drag gives a replace on the timeline, same as the canvas (the earlier point is fixed).
• Alt held through the drag: 4 selected became 3 live and stayed 3 on release; a band that covers nothing leaves the selection alone.
• The touched suites pass (149 tests); with the subtract path disabled, 11 of them fail across timelineMarquee, useDomSelection and useTimelineRangeSelection.

One thing left before it can land: the required "Studio and player captures" check wants ## Before and ## After sections in the PR description (for changes under packages/studio). Add both headings on GitHub and drag a screenshot under each, for example the timeline with Alt held mid-drag and the selection after release. Once that check is green, auto-merge takes it in. "Studio: timeline viewport gate" also fails the same way on main, so that one isn't from your change.

Re-approving after the rebase onto main: the patch is byte-identical to the one reviewed.