mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-01 19:42:03 +00:00
Vance Ingalls
dd0626a55a
Reported as "the grouping button did nothing — I clicked it and nothing happened". The dialog WAS opening. It positioned itself at `anchorRect.bottom + 4` with no flip and no clamp, and this button lives in a track header at the bottom of the studio window, so it opened past the viewport edge. It was the last floating surface in the timeline with no viewport handling at all. It now goes through `resolveFloatingPanelPosition`, the helper the other body portals already position with (`RenderQueue`, `propertyPanelColor`), so it flips above the anchor when there is no room below and clamps so neither edge leaves the viewport. `GROUP_DIALOG_SIZE` is a declared estimate in the same style as `FORMAT_PANEL_SIZE` and `COLOR_PICKER_SIZE`: `w-56` is exact, only the flip decision reads the height, and the clamp keeps the dialog on screen either way. Two tests, at a realistic bottom-of-window anchor and hard against the right edge. Both verified to fail against the raw positioning. Worth noting why this shipped: the existing `group-pointer` test passes with or without the fix. happy-dom reports an all-zero rect for an unlaid-out button, so the dialog landed at top:4 — on screen, and nothing like the real app. A geometry test that never sets a geometry proves nothing. Deliberately NOT included: a toast for the grouping write's silent `elements.length < 2` bail. That path is real in code but I could not reach it from the UI — the button only renders on a track with 2+ ungrouped clips, and sub-composition audio arrives as separate single-clip rows, so the offer never appears there. Adding a message for an unreachable branch, plus the file split it would force to stay under the 600-line studio cap, is not justified by evidence.