What problem does this solve?
# Issue: Public Selection API Doesn't Expose Table (`CellSelection`) Selections
## Summary
I'm building a custom context menu extension that operates on the current selection.
For normal text selections, everything works as expected:
- `editor.doc.selection.current({ includeText: true })` returns the selected text.
- `selection.target` contains the selected range.
- Custom context menu items appear correctly.
However, when selecting an entire table using the table selection handle, the editor creates a ProseMirror `CellSelection`, but the public selection API does not expose it.
## Current Behavior
The underlying editor state correctly contains a `CellSelection`:
```ts
superdoc.activeEditor.view.state.selection
```
Returns:
```ts
CellSelection
```
with valid:
- `$anchorCell`
- `$headCell`
- `ranges`
However, the public API returns:
```ts
await editor.doc.selection.current({
includeText: true,
})
```
```ts
{
empty: false,
text: "",
target: null,
selectionTarget: null
}
```
Likewise:
```ts
ui.viewport.contextAt(...)
```
returns:
```ts
selection: {
empty: false,
target: null,
selectionTarget: null,
quotedText: ""
}
```
## Expected Behavior
When the current selection is a table (`CellSelection`), the public selection API should expose enough information for extensions to detect and operate on it.
For example, one of the following would work:
- Return a non-null `selectionTarget`/`target` representing the selected table or cells.
- Expose a selection type (e.g. `"cell"` or `"table"`).
- Surface the underlying `CellSelection` (or equivalent metadata) through the public API.
## Problem
Because `CellSelection` is not surfaced through the public selection API, custom context menu extensions cannot determine that an entire table is selected, even though the editor internally has that information.
This makes it impossible to implement table-specific context menu actions using only the supported extension APIs.
## Question
Is there a supported way for extensions to detect a `CellSelection` or whole-table selection through the public API, or is exposing table selections something that could be added?Proposed solution
Here's a polished Markdown version of your proposed solution:
## Proposed Solution
Expose table selections (`CellSelection`) through the public selection API in the same way text selections are exposed.
For example:
```ts
const selection = await editor.doc.selection.current();
console.log(selection);
```
could return something like:
```ts
{
empty: false,
target: {
kind: "table",
tableId: "...",
anchorCell: { ... },
headCell: { ... }
}
}
```
The exact shape is less important than exposing enough information for extensions to:
- Detect when the current selection is a table (`CellSelection`).
- Access the selected table or cell range.
- Perform operations such as replacing, transforming, or analyzing the selected table.
Similarly, `ui.viewport.contextAt()` should expose the same selection metadata so custom context menu extensions can behave consistently for both text and table selections.
This would allow extension authors to support table-specific actions using only the public API, without relying on internal editor state or ProseMirror implementation details.Alternatives considered
## Current Workaround
The only workaround I've found is to access the underlying ProseMirror selection directly:
```ts
superdoc.activeEditor.view.state.selection
```
When a table is selected, this correctly returns a `CellSelection` containing the expected metadata, including the anchor and head cells.
However, this approach relies on internal editor implementation details rather than the public API. As a result, extensions that are intended to use only the documented APIs cannot reliably detect or operate on table selections, making this workaround fragile and potentially incompatible with future changes.
Additional context
## Steps to Reproduce
1. Create a table in the editor.
2. Select the entire table using the table selection handle.
3. Right-click to open a custom context menu.
4. Inspect the current selection:
```ts
await editor.doc.selection.current({
includeText: true,
});
```
### Actual Result
The public selection API returns:
```ts
{
empty: false,
target: null,
selectionTarget: null,
text: ""
}
```
However, inspecting the internal editor state:
```ts
superdoc.activeEditor.view.state.selection
```
returns a valid `CellSelection`.
### Expected Result
The public selection API (and `ui.viewport.contextAt()`) should expose enough information to identify and work with table (`CellSelection`) selections, just as it does for text selections.
This suggests that while table selections are fully supported internally, the corresponding selection information is not currently surfaced through the public selection and context APIs.
What problem does this solve?
Proposed solution
Here's a polished Markdown version of your proposed solution:
Alternatives considered
Additional context