Repository navigation
[lexical-table] Bug Fix: Cover a tapped empty table cell on iOS so a double tap cannot select past it - #9350
SujinKim1127 wants to merge 26 commits into
Conversation
… host on iOS ## Description On iOS, double tapping an empty table cell makes WebKit select back to the nearest preceding word, which lies outside the table when the cell is empty. meta#9267 restores the caret after `selectionchange`, which prevents the data loss, but iOS paints the native selection highlight before the page is notified, so the preceding content still flashes blue on every double tap (meta#9347). Nothing dispatched to the page can cancel that gesture: the second tap produces no cancelable event, and `::selection` / `user-select` do not affect the UIKit highlight. This change gives each table cell its own editing host on iOS so the word search never leaves the cell. `TableCellNode.createDOM` renders `<td contenteditable="false"><div data-lexical-table-cell-content contenteditable="true">` and `getDOMSlot` returns `slot.withElement(wrapper)`, so the reconciler places the cell's children inside the wrapper without any model change. `exportDOM` strips the wrapper and the `contenteditable` attribute, so copied and exported HTML keeps the existing `<td><p>` shape. Non-iOS DOM is unchanged. Two side effects of the nested host are handled in `LexicalTableSelectionHelpers`: - Backspace at the start of an empty cell would let WebKit move the caret into the previous editing host (the cell to the left). It is consumed for `deleteContentBackward` / `DELETE_CHARACTER_COMMAND` when the cell is empty and the caret is at its start. - The iOS selection UI fires `window.blur` before `selectionchange`, which cleared the `touchTapCellKey` marker from meta#9267 before it could be used. The marker is now kept for up to 500ms across that blur when the tapped cell is an empty wrapper cell, and a native range touching that cell is collapsed back to the cell start. Closes meta#9347 ## Test plan `IosTableCellEditingHost.test.ts` mocks `IS_IOS` (and `CAN_USE_BEFORE_INPUT`, which jsdom lacks) and pins the wrapper DOM shape, wrapper identity across added paragraphs, the editable toggle, the exported HTML, and the Backspace guard in both the empty and the non-empty cell. ### Before ``` $ pnpm exec vitest run packages/lexical-table/src/__tests__/unit/IosTableCellEditingHost.test.ts × renders the cell content inside a nested editing host × keeps the same editing host as paragraphs are added × follows the editable state of the editor × consumes Backspace at the start of an empty cell × leaves Backspace alone in a cell with text Tests 5 failed | 1 passed (6) ``` On an iPhone (iOS Safari and iOS Chrome) with the playground: insert a table below a paragraph, double tap an empty cell. The cells above and the end of the paragraph above the table are highlighted blue for one frame, then the caret returns to the cell. ### After ``` $ pnpm exec vitest run packages/lexical-table/src/__tests__/unit/IosTableCellEditingHost.test.ts Tests 6 passed (6) $ pnpm exec vitest run packages/lexical-table Test Files 26 passed (26) Tests 265 passed (265) $ pnpm exec vitest run --project browser packages/lexical-table/src/__tests__/browser/EmptyCellTouchSelection.test.ts Test Files 1 passed (1) Tests 30 passed (30) $ pnpm run tsc # 0 errors $ pnpm exec eslint <changed files> # ok $ pnpm exec prettier --check <changed files> # All matched files use Prettier code style! ``` Same device steps: nothing is highlighted and the caret stays in the cell. Also verified on device: typing in a previously empty cell (English with autocorrect, Korean IME), Enter creating several paragraphs, Backspace at an empty cell start staying in the cell, double tap on a cell with text selecting the word, selection-handle drag from the paragraph above into the table and from a cell out of the table, long-press drag across cells producing a table selection, tapping another cell moving the caret, table scrolling. Not exercised: arrow-key and Shift+arrow navigation across cells on iOS (no hardware keyboard available), and Android. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
lexical
@lexical/a11y
@lexical/clipboard
@lexical/code
@lexical/code-core
@lexical/code-prism
@lexical/code-shiki
@lexical/compiler
@lexical/devtools-core
@lexical/dragon
@lexical/eslint-plugin
@lexical/extension
@lexical/fast-check
@lexical/file
@lexical/hashtag
@lexical/headless
@lexical/history
@lexical/html
@lexical/internal
@lexical/link
@lexical/list
@lexical/mark
@lexical/markdown
@lexical/mdast
@lexical/offset
@lexical/overflow
@lexical/plain-text
@lexical/react
@lexical/rich-text
@lexical/selection
@lexical/table
@lexical/tailwind
@lexical/text
@lexical/utils
@lexical/y
@lexical/yjs
commit: |
… into fix/ios-table-cell-editing-host
![meta-code-review[bot]](https://avatars.githubusercontent.com/in/5334748?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thanks for reworking this around an overlay. That part is small, iOS-only, and keeps exported HTML and DOM child offsets intact through getDOMSlot(...).withBefore(...). One issue in the drag-caret module needs a fix before this can merge; the rest are optional suggestions.
Needs a fix: the caret can stay hidden after a touch (LexicalTableIOSDragCaret.ts:61)
registerIOSTableDragCaretHiding saves rootElement.style.caretColor at touchstart and writes that saved value back at touchend (and on teardown, line 77). The saved value is not always yours to restore. When the caret sits beside a block that cannot hold one, such as a table or a block decorator like an image, core shows the block cursor and sets caret-color: transparent. Removing the block cursor clears it again (removeDOMBlockCursorElement in packages/lexical/src/LexicalUtils.ts).
So if a long-press drag across cells starts while a block cursor is showing:
touchstartsavestransparent, the block cursor's value.- The drag commits a table selection while the finger is down, which removes the block cursor and clears
caret-color. touchendwritestransparentback.
Nothing clears it after that, so the caret is invisible in every paragraph and cell until a block cursor is next shown and removed. A long press that places the caret in a cell does the same. A unit test on the same harness as IosTableDragCaret.test.ts shows it: after those three steps, plus selecting text in the paragraph above, caretColor is still 'transparent' on this branch and '' on main.
A possible fix: at touchend, leave caret-color alone if it is no longer the transparent this module wrote. If the saved value came from the block cursor, restore it only while the block cursor is still in the DOM, and otherwise remove the property. Please add that sequence as a test. Splitting this module into its own PR, as you offered, would also work.
Optional suggestions
-
LexicalTableIOSEmptyCellOverlay.ts:144:cellDOM.contains(domSelection.anchorNode)reads the raw selection anchor. The "Shadow DOM and iframe realm safety" table inAGENTS.mdasks forgetDOMSelectionPoints(selection, rootElement)instead, as core's own iOS click handling does. In an editor inside a shadow root the anchor is retargeted to the host, so the pointerdown path for a cell that already holds the caret would never run there. -
Changeset: this changes what the published
@lexical/tabledoes on iOS, soAGENTS.md(Changesets) andCONTRIBUTING.mdask for an entry in.changeset/, with aVerify:paragraph for a fix that changes behaviour. For example:--- '@lexical/table': patch --- [fix] Double tapping an empty table cell on iOS no longer selects back to the text before the table Verify: on an iPhone, double tap an empty cell (also one that already holds the caret); single tap, long press and long-press drag across cells still behave as before.
-
Test plan output: the pasted Before block lists 18 tests ("9 failed | 9 passed") under names that are no longer in the files. At this head the two files hold 15 tests, and 8 of them fail against
main. "Commits and Pull Requests" inAGENTS.mdasks for the real Before and After output of the command that was run, so please re-paste it from the current files.
… iOS drag caret hiding ends
## Description
Addresses the review of this PR.
- The drag caret hiding saved the root's inline `caret-color` at `touchstart`
and wrote it back at `touchend`. Core's block cursor writes the same
property: `transparent` while shown, removed when it goes away. If a block
cursor was showing at `touchstart` and the gesture moved the selection
(a long-press drag committing a table selection), the block cursor went
away mid-gesture and `touchend` then wrote its `transparent` back, leaving
the caret hidden in the whole editor. The restore now leaves `caret-color`
alone if something else changed it during the gesture or the block cursor
(`[data-lexical-cursor]`) is shown, and removes the property instead of
restoring a `transparent` that came from a block cursor that is gone. The
same logic runs on teardown.
- The overlay reads the caret's cell through `getDOMSelectionPoints`, so a
tap on the cell holding the caret is also covered on `pointerdown` in an
editor inside a shadow root.
- Add a changeset for `@lexical/table`.
## Test plan
### Before
The new block cursor test against the previous restore:
```
$ pnpm exec vitest run packages/lexical-table/src/__tests__/unit/IosTableDragCaret.test.ts
× does not restore a block cursor value that went away mid-gesture
Tests 1 failed | 6 passed (7)
```
### After
```
$ pnpm exec vitest run packages/lexical-table/src/__tests__/unit/IosTableDragCaret.test.ts
Tests 7 passed (7)
$ pnpm exec vitest run packages/lexical-table
Test Files 31 passed (31)
Tests 300 passed (300)
$ pnpm exec vitest run --project browser packages/lexical-table/src/__tests__/browser
Tests 58 passed (58)
$ pnpm exec vitest run scripts/__tests__/unit/treeShakingSource.test.ts
Tests 374 passed (374)
```
Each `ci-check` step (`tsc`, `tsc-test`, `tsc-scripts`, `tsc-extension`,
`tsc-website`, `flow`, `prettier`, `lint`, `check-changesets`) exits 0. Not
re-checked on a device; the block cursor sequence was reproduced in a unit
test, and the shadow root path was not exercised.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Thanks for reworking this around a small overlay, as suggested earlier in this thread. The overlay part reads well: it is iOS-only, keeps DOM child offsets and exported HTML intact through getDOMSlot(...).withBefore(...), and the new tests separate the fix from main. One issue in the drag-caret module needs a fix before this can merge; the rest are optional suggestions.
Needs a fix: the caret can stay hidden after a touch (LexicalTableIOSDragCaret.ts:61)
registerIOSTableDragCaretHiding saves rootElement.style.caretColor at touchstart and writes it back at touchend (and on teardown, line 77). That saved value is not always this module's to restore. When the caret sits beside a block that cannot hold one (a horizontal rule, an image, or a table), core shows the block cursor and sets caret-color: transparent; removing the block cursor clears it again (removeDOMBlockCursorElement in packages/lexical/src/LexicalUtils.ts).
So when a touch on a cell starts while a block cursor is showing:
touchstartsavestransparent, the block cursor's value.- The caret moves into the table while the finger is down (a long press, or the table selection a long-press drag commits). That removes the block cursor and clears
caret-color. touchendwritestransparentback.
Nothing clears it after that, so the caret is invisible in every paragraph and cell until a block cursor is next shown and removed. On main the caret comes back as soon as the block cursor goes. The reverse case is off too: if the block cursor appears during the touch, touchend restores '' and the native caret shows beside the block cursor.
A possible fix: at touchend and on teardown, restore the saved value only while the root still has the transparent this module set, and leave caret-color alone while a block cursor is in the DOM. Please add the three steps above as a case in IosTableDragCaret.test.ts: put the caret beside the table with $getRoot().select(n, n) on a focused root so the block cursor shows, fire touchstart on a cell, move the selection into that cell, fire touchend, then expect caretColor not to be 'transparent'. Splitting this module into its own PR, as you offered, would also work.
Optional suggestions
-
LexicalTableIOSEmptyCellOverlay.ts:144:cellDOM.contains(domSelection.anchorNode)reads the raw selection anchor. The "Shadow DOM and iframe realm safety" table inAGENTS.mdasks forgetDOMSelectionPoints(selection, rootElement)instead, because a selection inside a shadow root is retargeted to the host. In a shadow-root editor the pointerdown path for a cell that already holds the caret never runs. -
LexicalTableIOSDragCaret.ts:48:target.closest('td,th')can match a table cell outside the editor, for example when the editor itself sits inside a page's<td>, and then the caret is hidden on every touch. CheckingrootElement.contains(cell), as the overlay module does, keeps it to the editor's own tables. -
Changeset: this changes what the published
@lexical/tabledoes on iOS, soAGENTS.md(Changesets) and.changeset/README.mdask for an entry, with aVerify:paragraph for a fix that changes behaviour. For example:--- '@lexical/table': patch --- [fix] Double tapping an empty table cell on iOS no longer selects back to the text before the table Verify: on an iPhone, double tap an empty cell (also one that already holds the caret); single tap, long press and long-press drag across cells still behave as before.
-
Test plan: the pasted Before output lists 18 tests under names that no longer exist (for example
only the most recently tapped cell is covered); the two files now hold 15.AGENTS.md(Commits and Pull Requests) asks for the real Before and After output of the command that was run, so please re-paste it from the current branch.
| if (restoreCaretColor === null || event.touches.length > 0) { | ||
| return; | ||
| } | ||
| rootElement.style.caretColor = restoreCaretColor; |
There was a problem hiding this comment.
This writes back the value saved at touchstart, which can be the block cursor's caret-color: transparent. If the caret moved into the table during the touch, core has already removed the block cursor and cleared the property, so this leaves the caret invisible in the whole editor until a block cursor is shown and removed again. Restoring only while the root still has the transparent this module set, and never while a block cursor is in the DOM, avoids it (line 77 needs the same).
… into fix/ios-table-cell-editing-host
…e the editor
## Description
`registerIOSTableDragCaretHiding` hid the caret when `closest('td,th')` found any cell, so an editor that itself sits in a page's `<td>` hid its caret on every touch until the finger lifted. It now only hides it for a cell inside the editor root, as the empty cell overlay already does.
## Test plan
### Before
```
$ pnpm exec vitest run packages/lexical-table/src/__tests__/unit/IosTableDragCaret.test.ts
× leaves the caret alone for an editor that sits in a page table cell 6ms
AssertionError: expected 'transparent' to be '' // Object.is equality
Tests 1 failed | 7 passed (8)
```
### After
```
$ pnpm exec vitest run packages/lexical-table
Test Files 35 passed (35)
Tests 315 passed (315)
```
Not exercised on a device: an editor inside a page table cell.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Thanks for the quick follow-up on the block-cursor case and for adding the changeset. The restore now leaves caret-color alone when the block cursor owns it, and the new test fails against the previous version of the module, which is exactly what it should pin. One issue in the same module still needs a fix before this can merge; the other two points are optional.
Needs a fix: the caret can stay hidden after a touch that outlives the overlay (LexicalTableIOSDragCaret.ts:91-95)
registerIOSTableDragCaretHiding restores caret-color only from touchend/touchcancel listeners on the window. A touch's events stay targeted at the element the touch started on, even after that element is removed from the document, and then they no longer bubble to the window (MDN: Touch.target). The empty-cell overlay is removed by its 500 ms timer (LexicalTableIOSEmptyCellOverlay.ts:88 and :121), so a second touch that starts on the overlay and is still down when the window ends (a tap roughly 400 ms after the first, or a press-and-hold) lifts on a detached element. restore never runs, and the caret stays invisible while typing in the cell until some later touch on the page ends.
To reproduce in the playground on an iPhone: tap an empty cell, tap it again a little under half a second later and hold it slightly longer, then type. In iPhone-emulated Chromium with real touch input, the root keeps caret-color: transparent after the lift and after typing; on main the caret stays visible.
A small fix: in onTouchStart, also add {once: true} touchend and touchcancel listeners to the touch's own target, which is the practice MDN recommends when a touched element can be removed. Keeping the overlay until a touch that started on it ends would also work. A unit test along these lines (combining helpers from the two new test files, with fake timers) would pin it:
tapCell(0); // covers the empty cell
const overlay = overlayOf(0)!;
vi.advanceTimersByTime(420);
touch(overlay, 'touchstart'); // the caret is hidden
vi.advanceTimersByTime(150); // the window ends and the overlay is removed
touch(overlay, 'touchend'); // the lift reaches only the detached overlay
expect(container.style.caretColor).not.toBe('transparent');If you would rather land the overlay on its own, splitting the drag-caret module into a separate PR, as you offered in the description, works too.
Optional
LexicalTableIOSDragCaret.ts:57-59: theremovePropertybranch only runs when the savedtransparentwas not the block cursor's, because when the block cursor goes away mid-gesture core has already cleared the property and the early return at:51handles it. So an app that hides the native caret with an inlinecaret-color: transparenton the root gets it back after any table-cell touch. Writingsavedback in every case matches the description ("restored (to any previous inline value)") and keeps all seven drag-caret tests passing.- In the cell that already holds the caret, the overlay is added on
pointerdown(LexicalTableIOSEmptyCellOverlay.ts:136-150), so that tap's click lands on the overlay. Tapping the insertion point is also how iOS shows the Paste menu; could you note under the Test plan's After whether that still works in an empty cell?
| registerEventListeners( | ||
| view, | ||
| {touchcancel: onTouchEnd, touchend: onTouchEnd}, | ||
| options, | ||
| ), |
There was a problem hiding this comment.
These window listeners miss the lift when the touch started on an element that was removed during the touch: touch events stay targeted at the original element and no longer bubble to the window (MDN: Touch.target). The empty-cell overlay is removed by its 500 ms timer, so a second touch that starts on it and outlasts the window leaves caret-color: transparent on the root while the user types. Adding {once: true} touchend/touchcancel listeners to the touch's own target in onTouchStart fixes it.
There was a problem hiding this comment.
Fixed in 02eccf0: the touch's own target now gets touchend/touchcancel listeners too.
| if (saved === 'transparent') { | ||
| // That was the block cursor's value, and it is gone. | ||
| rootElement.style.removeProperty('caret-color'); |
There was a problem hiding this comment.
Optional: when the block cursor goes away mid-gesture, core has already removed the property, so the early return above handles it and this branch only runs when the saved transparent was not the block cursor's (for example an app's own inline value). Writing saved back here too keeps "any previous inline value" and the existing tests still pass.
There was a problem hiding this comment.
Done in 02eccf0: the saved value is always written back.
…overlay is removed mid-touch
## Description
`registerIOSTableDragCaretHiding` restored `caret-color` only from `touchend`/`touchcancel` listeners on the window. A touch keeps its original target even after that element leaves the document, and its events then no longer reach the window. The empty cell overlay is removed by its 500ms timer, so a second tap that started on it and was still down when the window ended left the caret hidden while typing in the cell. The lift is now also listened for on the touch's own target, and those listeners go away when the caret is restored.
The restore also writes the saved inline value back in every case. The branch that removed the property instead only ran when the saved `transparent` was not the block cursor's (an app's own inline value), because core clears the property itself when the block cursor goes away.
## Test plan
### Before
```
$ pnpm exec vitest run packages/lexical-table/src/__tests__/unit/IosEmptyCellOverlay.test.ts
× a touch on the overlay that outlasts it still restores the caret 10ms
AssertionError: expected 'transparent' to be '' // Object.is equality
Tests 1 failed | 10 passed (11)
```
### After
```
$ pnpm exec vitest run packages/lexical-table
Test Files 35 passed (35)
Tests 316 passed (316)
$ pnpm run tsc && pnpm run tsc-test # 0 errors
$ pnpm run flow # Found 0 errors
```
Not exercised on a device yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks for the reviews. Everything from all three is addressed. Required fixes
Optional suggestions
Re-checked on an iPhone:
A block cursor can't be shown by touch alone, so that case is covered by the unit tests. |
There was a problem hiding this comment.
Thanks for reworking this along the lines suggested earlier. This looks good to me: the overlay is a much smaller change than the per-cell editing host, JSON and exported HTML are unchanged, no public export changes, and the new tests fail on main and pass here. The points below are optional and non-blocking.
- Wrapped cell slots during the overlay window (
packages/lexical-table/src/LexicalTableCellNode.ts,getDOMSlot). The cell's slot now gets the overlay as itsbeforeboundary. ATableCellNodesubclass or adomOverridethat wraps the cell's children the waypackages/lexical-website/docs/serialization/dom-render.md("Customizing the slot for an ElementNode") shows, withwithElement(inner), keeps that boundary, so adding a block to the cell within the 500 ms window fails withDOMSlot.insertChild: before is not in element.getDOMSlotis experimental and nothing in the repository does this today, but a small guard incoverCell(skip the cell whencell.getDOMSlot(cellDOM).element !== cellDOM) would keep the overlay to cells that use the default slot. - Scope of the caret hiding (
packages/lexical-table/src/LexicalTableIOSDragCaret.ts,onTouchStart). The root'scaret-colorgoes transparent for any touch that starts on a cell, including a long press that moves the caret inside a cell with text, or a scroll that starts on the table while the caret is in a paragraph elsewhere. Because it is set on the root, the in-page caret disappears wherever it is for the whole touch. Since the flicker comes from the table selection clearing the native caret, starting the hiding once a touch drag has turned into a table selection may be enough. Your offer to split this module into its own PR also sounds reasonable; it would let #9347 land with the overlay alone. - A browser-tier test for the hit-test. AGENTS.md ("Testing Strategy") puts behavior that depends on real layout under
packages/**/__tests__/browser/**. The jsdom tests cover the overlay's lifecycle well; a browser-mode test that mocksIS_IOSthe same way, taps an empty cell and checkselementFromPointat its centre would also cover the part of the fix that does not need an iPhone. - Nit:
aria-hidden="true"on the overlay would keep VoiceOver from treating the transient element as content.
| // offsets still match the node's children. | ||
| const last = element.lastElementChild; | ||
| return last !== null && last.hasAttribute(EMPTY_CELL_OVERLAY_ATTRIBUTE) | ||
| ? slot.withBefore(last) |
There was a problem hiding this comment.
Optional: a TableCellNode subclass or domOverride that wraps the cell's children with withElement(inner) (the pattern in packages/lexical-website/docs/serialization/dom-render.md) keeps this before, which is a child of the <td>, not of inner. Adding a block to the cell within the 500 ms window then fails DOMSlot.insertChild: before is not in element. Skipping the overlay in coverCell when cell.getDOMSlot(cellDOM).element !== cellDOM would avoid it.
| return; | ||
| } | ||
| restoreCaretColor = rootElement.style.caretColor; | ||
| rootElement.style.caretColor = 'transparent'; |
There was a problem hiding this comment.
Optional: this runs for every touch that starts on a cell, including a long press that moves the caret within a cell or a scroll that starts on the table, and since it is set on the root the caret is hidden wherever it is. Starting the hiding once a touch drag has become a table selection may be enough for the flicker this targets.
| clear(); | ||
| const overlay = rootElement.ownerDocument.createElement('div'); | ||
| overlay.setAttribute(EMPTY_CELL_OVERLAY_ATTRIBUTE, 'true'); | ||
| overlay.contentEditable = 'false'; |
There was a problem hiding this comment.
Nit: overlay.setAttribute('aria-hidden', 'true') would keep VoiceOver from treating the transient overlay as content.
Description
On iOS, double tapping an empty table cell makes WebKit select back to the nearest preceding word, which lies outside the table. #9267 restores the caret after
selectionchange, but iOS paints the native highlight before the page is notified, so the preceding content still flashes on every double tap (#9347). The second tap dispatches no cancelable event, and page CSS does not affect the highlight.Empty cell overlay (
LexicalTableIOSEmptyCellOverlay.ts)contenteditable="false"overlay. A second tap in that window lands on the overlay instead of editable text, so iOS does not start a word selection, and the overlay places the caret in the cell.pointerup, after a short, still touch. When the cell already holds the caret, iOS withholds that tap'spointerupuntil it knows whether a second tap follows, so that cell is covered onpointerdowninstead.pointercancel), never adds it.positionis restored with it.TableCellNode.getDOMSlotkeeps the cell's children before the overlay withwithBefore, so DOM child offsets still match the node's children. The overlay is never part ofcreateDOM, so exported HTML is unchanged.Drag caret (
LexicalTableIOSDragCaret.ts)caret-coloris made transparent while a finger is down on a cell, and restored (to any previous inline value) when the last finger lifts, including a lift on an element removed during the touch, such as the overlay. Only cells inside the editor count, so an editor that sits in a page's<td>is left alone. It leavescaret-colorto core's block cursor when that cursor is shown or changed it during the gesture.caret-color. I'm happy to split this into its own PR if you'd prefer.Both are registered from
registerTableSelectionObserveron iOS only. InLexicalTableSelectionHelpers, the #9267 repair now uses the shared$isCellEmpty(LexicalTableUtils) for its empty cell check, andTAP_SLOPmoved toconstantsso the overlay can share it; neither changes behavior. Non-iOS behavior and DOM are unchanged.Closes #9347
Test plan
IosEmptyCellOverlay.test.tsandIosTableDragCaret.test.tsmockIS_IOS.Before
ScreenRecording_10-12-2026.16-51-09_1.mov
On an iPhone (iOS Safari) with the playground: double tapping an empty cell flashes the cells above and the end of the paragraph above the table. A long press drag across cells starting from an empty cell paints the cells with the caret flickering throughout.
With the
lexical-tablesources atmain:After
ScreenRecording_10-23-2026.15-34-02_1.mov
On the same iPhone with the playground:
Not exercised: iPadOS, Android (the code is iOS-only), and hardware keyboard navigation.
🤖 Generated with Claude Code