-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[lexical-playground] Chore: Add (disabled) E2E tests for nested table drag-selection #8107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[lexical-playground] Chore: Add (disabled) E2E tests for nested table drag-selection #8107
Conversation
assertion is incorrect, will adjust after implementation is fixed
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| if (mouseDown) { | ||
| await page.mouse.down(); | ||
| } | ||
| await page.mouse.move(toX, toY, slow ? 10 : 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this argument was wrong? The dragging behaviour was only testable once I used the steps parameter instead of passing the number in. https://playwright.dev/docs/api/class-mouse#mouse-move
I changed the function to take the number of steps rather than a boolean, and reduced the "slow" value from 10 to 5 to speed up some tests (at 10 steps, the test takes an additional 200ms)
etrepum
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the table handling code should be monolithic, and I'm sure that it could be made more efficient with some API changes. The last refactor of that code was focused on fixing bugs without the sort of structural changes it really needs.
I think these are legit e2e test failures, but github has been having issues today so I restarted them. Some of these changes might break existing tests?
Description
I was working on a fix for #7154, that is, improving the selection behaviour for nested cells.
I gave up on the fix because the current selection handler in
LexicalTableSelectionHelpers.tsis registered for each table. As it stands, a selection in a nested cell is also considered a selection inside the parent cell. Both tables end up firing $setSelection and triggering each othersSELECTION_CHANGED_COMMAND, and they end up fighting for control. This leads to flickering and the wrong element being selected, see:Screen.Recording.2026-02-02.at.2.23.41.pm.mov
I would like to refactor table selection to use a monolithic handler which is only registered and fired once.
I propose merging these test to demonstrate the bug and then refactoring (with a fix for these tests) in another PR.
Test plan
Before
Visual demonstration of the E2E tests (if the
.fixmeis removed). Apologies for the poor quality, had to downscale to fit Github limits.Screen.Recording.2026-02-02.at.2.14.40.pm.mov
After
No changes to logic.