Bug Fix : fix cursor looping and incorrect paragraph insertion after tables

[Jynx2004]

Description

This PR fixes an issue where cursor navigation becomes inconsistent when a table is the final block in the document.

Fixes #7999

Problem

When a table is the last node and all content after it is deleted:

• Clicking to the right of the table briefly places the cursor there, then moves it back into the last table cell
• Repeatedly pressing the right arrow key causes the cursor to loop between:
  • The last table cell
  • A block cursor beneath the table
  • The right-hand side of the table
• Pressing Enter while the cursor appears on the right-hand side of the table inserts a new paragraph above the table instead of below it

This makes it difficult for users to understand how to add content after a table.

Cause

When there is no text in the direction of navigation, Lexical attempts to explore adjacent nodes. If the previous node is a table, this logic re-enters table selection and causes the cursor to cycle back into the table.

Fix

Short-circuit navigation/deletion logic when:

• There is no text in the navigation direction, and
• The immediately preceding node is a table

This prevents Lexical from re-entering table selection logic and allows the cursor to correctly move and remain below the table.

Result

• Cursor moves beneath the table when navigating right from the last cell
• Cursor no longer cycles back into the table
• Pressing Enter inserts a paragraph after the table
• Matches expected behavior of common rich-text editors

Impact

Primarily a polish improvement, but significantly improves usability and prevents user confusion when editing content after tables.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
lexical	Ready	Preview, Comment	Dec 16, 2025 5:31pm
lexical-playground	Ready	Preview, Comment	Dec 16, 2025 5:31pm

[etrepum]

This isn't a complete workaround and it does not add any tests to show that it works as expected

[etrepum]

This is better written as anchorNode.getPreviousSibling()

[etrepum]

This is not an acceptable solution because LexicalSelection shouldn't know about tables and the type of a table could be any string (in situations where a node override is used to replace TableNode with a subclass)

[Jynx2004]

How can we identify the paragraph node which is just after the table in hierarchy other than the above method ?
If we recognize it then we can prevent deletion of it which resolves the bug.