Let the host choose where the context menu renders

[rolfheij-sil]

The editor's right-click context menu always portalled to document.body. A host that scales its content (Platform.Bible zooms a pane's content with CSS zoom) therefore got a menu at interface scale beside text twice its size, and the menu was bounded by the window rather than by the pane.

EditorOptions gains an optional contextMenuContainer getter naming the element to render into. Inside that element the menu inherits the area's zoom and is bounded by it. Hosts that pass nothing are unaffected.

contextMenuContainer?: () => HTMLElement | undefined;

What the plugin does when a container is supplied

• Portals into it, so the menu inherits the element's CSS zoom.
• Converts the pointer's viewport pixels into the menu's own units. zoom multiplies a position: fixed element's own left/top, so writing viewport pixels straight would place the menu at the factor times its intended point. The factor is measured, not read from currentCSSZoom: a transform: scale() above the menu multiplies it too and currentCSSZoom cannot see that, so the menu's rendered width is compared against the 200px it was written with.
• Clamps to the container's visible box — the container's rect narrowed by every clipping ancestor and then the viewport. The container is often the scrollable content, taller than the visible pane, and a position: fixed element is not clipped by a scrolling ancestor, so staying inside the pane has to be computed rather than inherited.
• Caps both axes to that box, in its own units, with overflow-y: auto. Width matters as much as height: the menu's 200px is fixed, so the zoom multiplies it, and past roughly 150 % in a narrow pane the horizontal clamp has nothing left to give and the surplus paints past the pane's edge.
• Falls back to the viewport if the visible box comes out empty, which a clipping ancestor with no layout of its own would otherwise cause. An unbounded menu beats an invisible one.
• Recovers its containing block's origin by reading back where it actually landed. A transform on any ancestor (unlike zoom) re-parents the containing block of a position: fixed descendant, which is exactly what happens inside a Radix popover. Rather than trying to detect that — it is also caused by filter, contain, will-change and others — the menu measures where it went, derives the origin, and solves for the offsets. Exact in one pass for any axis-aligned scale and translation.

The getter is resolved once, when the menu opens, inside the contextmenu handler, and never during render: an opaque call during render makes the React Compiler abandon optimizing the component.

Browser behaviour this rests on

Measured in Chromium rather than assumed:

question	result
Does position: fixed inside zoom: 2 get scaled?	Yes — left: 100px renders at viewport x = 200
Does zoom create a containing block for it?	No — it resolves against the viewport, so it escapes a scrolling ancestor
Does a transform ancestor create one?	Yes — a child written 350/180 inside zoom:2 inside translate(620,310) rendered at 1320/670 instead of 700/360
Is Element.currentCSSZoom available?	Yes, and it reports the cumulative CSS zoom — but not a transform: scale(), which is why placement measures instead
Do hard-coded px lengths scale under zoom?	Yes — a 14px item renders at 28px

That last row is why the menu's hard-coded 14px font and 200px width are unchanged: they already scale correctly, and altering them would only restyle the menu at 100 %.

Also fixed

Scrolling the menu closed it. The plugin's capture-phase scroll listener on window also receives scroll events from descendants, so wheeling a scrollable menu dismissed it and made clipped items unreachable by mouse. Scrolls originating inside the menu are now ignored; scrolls elsewhere still close it. This was partly pre-existing — the inner list has always been scrollable — so the fix helps unzoomed hosts too.

Note for reviewers: the generated diff

packages/platform/dist/ and packages/platform/etc/platform-editor.api.md are committed build output, regenerated with nx extract-api platform-editor. dist/index.js shows roughly 5k changed lines for a small source change — that is bundler identifier churn, not hand-written code. verify-committed-dist.mjs rebuilds and byte-compares it, and passes.

Tests

ContextMenuPlugin had no test file; it now has 18 tests. Each asserts exact pixel values rather than inequalities, and each was proven to fail against the line it covers before being kept. Full shared-react suite green (1672 passed).

The layout stub scales the size it reports by the same factor as the position and honours the caps the code writes, so it models the browser rather than restating the implementation's own assumption — without that, no test could exercise clamping at a zoom other than 1. The stub is still a model: that CSS zoom scales a position: fixed descendant this way is established by the Chromium measurements above and by hand testing, not by the suite.

Verified by hand at 200 %: the menu scales, lands at the pointer, stays inside the pane in a split layout, and behaves inside the footnote editor pop-up. The width cap and the measured-scale placement landed after that hand test and need re-checking, in particular in a narrow pane at 200 % and above.

Known, not addressed here

The menu's list carries the stylesheet's own max-height: 200px with its scrollbar hidden (scrollbar-width: none), and at ~32px an item a 7-item menu already exceeds it at 100 % zoom — so the last item is reachable only by wheel, with no scrollbar to show it. That is pre-existing and independent of this change; the height cap here adds a second, visible scroll region on top of it in a short pane. Arrow-key navigation also does not scroll the selected item into view, same pre-existing cause.

And one the width cap introduces: the list items carry min-width: 180px, so where the cap lands below roughly 196 of the menu's own pixels — a pane under about 390px at 200 % — the items cannot shrink to fit and the labels are clipped behind a horizontal scrollbar instead. Keeping the menu inside the pane is still the better of the two failures, and letting the items shrink means changing the shared stylesheet, which reaches hosts that pass no container at all.

AI-assisted — session

🤖 Generated with Claude Code

---

This change is