Conversation
Add an actionMenuPlacement editor prop ('bottom' | 'top', default 'bottom').
Tooltips and popovers inside the menu open away from the docked edge.
Mobile keeps the bottom rail.
A floating top menu is centered on the whole viewer, so it overlaps the host's toolbar groups and covers the camera controls hint. In layout v2 the menu now sits in a new center slot of the toolbar row, between the side groups and level with them; the camera hint moves below it. Layout v1 keeps a floating menu at the top edge.
The side groups are normally the same height, so nothing moves by default; a host that stacks a group vertically on narrow windows no longer pushes the other group down.
When the side groups and the docked menu don't fit in one row, the menu moves to its own centered row below the side groups instead of pushing the right group out of view. The layout publishes where the toolbar ends, and the level selector and camera hint sit below that, so nothing they cover changes with the row height. With the default bottom menu nothing moves. The camera hint also only makes room for a top menu that is really docked (not on mobile).
|
What this does Adds an opt-in
Best place to start: the |
ivnnv
changed the title
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
When the menu does not fit inline it goes under the left group if the right group is tall enough to leave room there, else on its own full-width row. Only the menu takes clicks on that row, so the empty space beside it still reaches the canvas. Each side of the toolbar publishes its own bottom edge and the inspector column sits below the right side instead of a fixed top-20.
| const centerBox = centerRef.current | ||
| column.style.setProperty( | ||
| '--viewer-toolbar-bottom', | ||
| `${Math.max(bottomOf(leftRef.current), bottomOf(centerBox))}px`, |
There was a problem hiding this comment.
Overlay offset double-counts toolbar top
Medium Severity
--viewer-toolbar-bottom is written as a column-relative Y, including the toolbar's top-3 offset, but consumers still add 0.75rem on a fallback that is only content height. On v2 the level selector, camera hint, and RightStack therefore sit about 12px lower than before, including with the default bottom menu.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit d6676e2. Configure here.
There was a problem hiding this comment.
i dont think so, the measured bottom and the 2.75rem fallback are both top-3 + the 32px row (44px), so +0.75rem lands on the same 56px as the old top-14. checked default before/after, level selector and hint at 56, inspector at 80
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.
There are 3 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 25612a8. Configure here.
…top menu The camera hint now sits below the full toolbar height, so a taller right group or a missing left group can't put it inside the toolbar row. With the menu docked at the top, the inspector column no longer keeps the bottom clearance meant for a bottom menu.
This branch has not been deployed
1 participant
Right now the viewer loses two strips of space, the top one for the toolbar row and the bottom one for the action menu, and hosts cant change that since the menu position is hardcoded in the editor (just floating it at the top doesnt work either, as its centered on the whole viewer so it lands on top of the toolbar groups and covers the camera controls hint, 2nd screenshot). Docking the menu into the toolbar row gives the whole bottom strip back to the canvas.
This adds an opt-in
actionMenuPlacementprop toEditor('bottom'by default so nothing changes for anyone, or'top'). With'top'the v2 layout renders the menu in a new center slot of the viewer toolbar row, in between the side groups and at the same height (tooltips and popovers inside it open downwards). When the three dont fit in one row the menu goes under the left group if theres room beside a taller right group, otherwise on its own centered row, and the level selector and camera hint now sit under wherever the toolbar actually ends instead of a fixed offset, so nothing gets covered (with the default bottom menu they stay exactly where they were). On the older v1 layout it just floats at the top edge, and mobile keeps the bottom rail as it is.actionMenuPlacement="top": docked in the toolbar row, bottom strip freeNote
Low Risk
UI layout and overlay positioning only; default
bottompreserves existing behavior, with resize-driven CSS vars as the main integration surface for hosts.Overview
Adds an opt-in
actionMenuPlacementprop onEditor('bottom'default,'top'to dock the action menu at the top). On layout v2 desktop,'top'renders the menu inline in a new center viewer-toolbar slot between left/right groups instead of as a bottom floater, freeing the bottom canvas strip.EditorLayoutV2gainsviewerToolbarCenterand responsive toolbar layout: aResizeObserverchooses inline vs wrapped placement and sets CSS variables (--viewer-toolbar-bottom,--viewer-toolbar-right-bottom,--viewer-toolbar-full-bottom) so overlays track the real toolbar height.ActionMenusupportsplacementandinline; a placement context drives tooltip/popover direction (open away from the dock edge). Floating level selector, camera controls hint, andRightStackuse those variables (andreserveBottomMenu) to avoid overlapping the toolbar or bottom menu. v1 can float the menu at the top; mobile stays bottom-docked.ActionMenuPlacementis exported for hosts.Reviewed by Cursor Bugbot for commit 5dd2291. Bugbot is set up for automated code reviews on this repo. Configure here.