fix(context-menu): open editor menu on right-click over resize overlays#3750
Conversation
The table and image resize overlays (the column/row resize handles shown on hover) render as siblings of the editor surface rather than inside it. A right-click landing on one of their handles therefore fell outside the context-menu target surfaces, so SuperDoc never called preventDefault and the browser's native context menu appeared instead of the editor menu. Treat targets within `.superdoc-table-resize-overlay` and `.superdoc-image-resize-overlay` as in-editor so the custom context menu (e.g. "Edit table") opens reliably. The table position is still resolved from the cursor coordinates, so the correct menu items are shown. Adds a pure `isWithinResizeOverlay` helper with unit tests. Co-authored-by: Cursor <cursoragent@cursor.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d5bcf94f24
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (isWithinResizeOverlay(target)) { | ||
| return true; |
There was a problem hiding this comment.
Scope resize overlay checks to this editor
When multiple SuperDoc editors are mounted, each ContextMenu instance has document-level contextmenu listeners, but this new early return treats any .superdoc-table-resize-overlay or .superdoc-image-resize-overlay in the document as belonging to this editor. Right-clicking a resize handle in editor A will therefore also make editor B's handler run, call preventDefault(), dispatch/open against editor B using editor A's coordinates, and potentially focus or show a stale menu for the wrong instance. Please only accept overlays associated with this ContextMenu's own .super-editor/surface before returning true.
Useful? React with 👍 / 👎.
Summary
Right-clicking on a table (or image) sometimes shows the browser's native context menu instead of SuperDoc's editor menu — reproducible whenever the blue resize handles are under the cursor. This makes actions like Edit table unreachable in that spot.


Before:
After:
Root cause
The table/image resize overlays (
.superdoc-table-resize-overlay/.superdoc-image-resize-overlay, rendered byTableResizeOverlay.vue/ImageResizeOverlay.vue) are mounted as siblings of the editor surface, not inside it:ContextMenu.vue'sisEventWithinContextMenuTargets()only treats the editor surface and the ProseMirror view DOM as in-editor. So when a right-click lands on a resize handle,handleRightClickbails early, never callsevent.preventDefault(), and the native menu wins. (The ProseMirrorhandleDOMEvents.contextmenuand thePresentationInputBridgeforwarder also skip it for the same reason.)Fix
Treat targets within the resize overlays as in-editor. Added a small pure helper
isWithinResizeOverlay(target)incontextmenu-helpers.jsand used it inisEventWithinContextMenuTargets(). Because the menu context (position,isInTable, etc.) is resolved from the cursor coordinates (getEditorContext→posAtCoords), the correct items (e.g. Edit table) are shown even though the DOM target is the overlay handle.Testing
pnpm exec vitest runfor the context-menu suite — all pass (165), including 3 new unit tests forisWithinResizeOverlay.Made with Cursor