Skip to content
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

Bug Fix: Fix issue where selecting a cell then dragging outside of table would not select entire table #6579

Merged
merged 9 commits into from
Sep 11, 2024

Conversation

moughxyz
Copy link
Contributor

@moughxyz moughxyz commented Aug 30, 2024

This fixes a regression caused by this PR.

The PR above aimed to solve a destructive issue where triple-clicking in a table could inadvertently select the entire document. The solution caused a regression where dragging out from inside a table wouldn't select the entire table, even though the highlight made it seem like it was selected.

I spent a bit of time trying to fix both the regression and the original triple-click issue but unfortunately had to reach a compromise where I could fix the regression, and fix the triple-click issue, with the compromise that triple-clicking the last cell would end up selecting the first cell (rather than the whole document). That's fine enough for me, so long as the whole document isn't selected, but isn't exactly technically correct.

However I couldn't figure out why the first cell was being selected. The code looks right to me and inspecting the selection before it's made tells me that the last cell should be selected, but for some reason, it's being overriden somewhere to the first cell.

In any case I think this PR represents a suitable compromise and we can either merge it now if it makes sense, or wait to see if someone understands what a fix could look like that addresses both issues.

Test plan

Tests were added and modified. I also added a utility function with the goal of making it easier to read and work with selection objects. Reading other people's selection objects, especially when reviewing the PR, is very hard to contextualize.

For example, this is hard to understand or conceptualize at first glance:

const expectedSelection = {
  anchorOffset: 0,
  anchorPath: [1, 0, 0],
  focusOffset: 9,
  focusPath: [2, 0, 0],
};

You'd have to print out the DOM to really verify what's going on here as a reviewer.

I've created a helper function that allows for self-describing names:

    const expectedSelection = createHumanReadableSelection({
      anchorOffset: {desc: 'beginning of cell', value: 0},
      anchorPath: [
        {desc: 'index of table in root', value: 1},
        {desc: 'first table row', value: 0},
        {desc: 'first cell', value: 0},
      ],
      focusOffset: {desc: 'full text length', value: 9},
      focusPath: [
        {desc: 'index of last paragraph', value: 2},
        {desc: 'index of first span', value: 0},
        {desc: 'index of text block', value: 0},
      ],
    });

Not required as part of this PR so I can remove it if it's not helpful.

Before

before.mov

After

after.mov

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Aug 30, 2024
Copy link

vercel bot commented Aug 30, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
lexical ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 8, 2024 6:32pm
lexical-playground ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 8, 2024 6:32pm

Copy link

github-actions bot commented Aug 30, 2024

size-limit report 📦

Path Size
lexical - cjs 29.61 KB (0%)
lexical - esm 29.49 KB (0%)
@lexical/rich-text - cjs 38.07 KB (0%)
@lexical/rich-text - esm 31.3 KB (0%)
@lexical/plain-text - cjs 36.72 KB (0%)
@lexical/plain-text - esm 28.65 KB (0%)
@lexical/react - cjs 39.89 KB (0%)
@lexical/react - esm 32.79 KB (0%)

@moughxyz
Copy link
Contributor Author

moughxyz commented Sep 2, 2024

FYI this test is pretty flakey: https://github.com/facebook/lexical/blob/main/packages/lexical-playground/__tests__/e2e/Tables.spec.mjs#L1307

Running it locally on macOS or Ubuntu 22.04 with cross-env E2E_BROWSER=chromium E2E_EDITOR_MODE=rich-text-with-collab E2E_EVENTS_MODE=modern-events playwright test --project=\"chromium\", I can get it to fail 1/5 times or so.

In debug I can see that the left frame correctly inserts the image in the second column second row, but on the right frame, it inserts the image in the first column second row. The test flakes even without the changes in this PR and without the changes in #6542.

The test was introduced in #2638 by @zurfyx.

@moughxyz
Copy link
Contributor Author

moughxyz commented Sep 2, 2024

@ivailop7 ready for review 🙏 If any suggestions please let me know.

@ivailop7
Copy link
Collaborator

ivailop7 commented Sep 8, 2024

Will have a look next week.

Copy link
Collaborator

@etrepum etrepum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it works to me, and all of the test suites are passing

@potatowagon potatowagon added this pull request to the merge queue Sep 11, 2024
Merged via the queue into facebook:main with commit 69bd14b Sep 11, 2024
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. extended-tests Run extended e2e tests on a PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants