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

Fixtable randomly causes table adding a huge amount of unexpected columns during collaboration #249

Open
qinwenshi opened this issue Oct 8, 2024 · 1 comment

Comments

@qinwenshi
Copy link

qinwenshi commented Oct 8, 2024

Abstract:

We are developing a system based on Tiptap. The underlying framework is ProseMirror + Yjs. The table component is developed based on prosemirror-tables.

We observed that when users intensively perform row and column operations (we will provide a method to reproduce this issue below), in some cases, it triggers infinite table growth. By "infinite growth," we mean that users can visually see the table columns rapidly expanding on the right side. This growth exhibits an uncontrolled trend, causing the document content to increase exponentially in a short period of time. As a result, the document contains too many DOM elements, making the rendering time excessively long and rendering the entire document, the browser crashed in the end.

image

Trigger method:

Suppose there is a 2×2 table in the document, with two users online simultaneously, namely user A and user B.

User A quickly adds columns to the end of the table.

User B quickly adds rows to the end of the table.

Analysis:

User A and User B will, at some point, both be in the following state, causing both to fix a cell in r3c3 simultaneously. The first fix makes the table complete, but the second fix will cause row 3 to have 4 cells. At this point, User A sees the table as complete, while User B sees an extra cell in the third row. This discrepancy causes User B to fix row 1 column 4 (R1C4) and row 2 column 4 (R2C4) again. This fix, when broadcasted to User A, triggers an infinite loop of fixtable.

x x a

x x a

b b X

Fix Discussion:

Could we make the fixtable operation idempotent? For example, when fixing r3c3, add a flag to the cell. The next time we attempt to fix r3c3, check if the flag already exists. If it does, stop the fix.

Log Investigation:

We added logs in fixtable.ts after calculating mustAdd. We observed that "fixTable mustAdd:[0,0,0,1,0,0]" was logged 119 times and "fixTable mustAdd:[1,1,1,0,1,1]" was logged 89 times. In summary, during the period of failure, logs related to fixTable mustAdd were called intensively.

@ocavue
Copy link
Collaborator

ocavue commented Oct 11, 2024

I would love to accept a PR for this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants