You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 1, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 1, 2026. It is now read-only.
When using IME for input in large amounts of text, the processes of composionstart, composionupdate, and composionend can cause frequent redrawing of the DOM, affecting the user experience. Is it possible to intercept the input of the compositionstart and compositionupdate processes, and then submit them uniformly to the prosemirror state in compositionsend? The commercial product Kingsoft Document should have used a similar solution.
We want the editor state to track the actual composition state. Freezing the editor until composition finishes has lots of disadvantages (extensions will appear unresponsive, on Android composition often only finishes when the user moves the cursor away from a composed word, etc).
What kind of expensive redrawing are you seeing? The view update should generally be a no-op during composition.
I cannot really make anything out in those scaled-down screenshots. Does this document perform well if you edit it as a plain contenteditable element? Where do the dev tools say the time is spent?
When a document contains a large amount of text, the input during the composition event process can cause the browser to layout, paint, and other processes. This process is slow for the browser itself, resulting in a poorer input experience. Therefore, I believe that changing the editor state after the composition event is completed can improve the user experience (at least on the PC side).
If I want to update the editor after the composition event is completed, could you give me a suggestion on how to modify the prosemirror-view input.ts code?
For example, I tryied to hung a virtual node on top of the editor node to receive composite events.
When a document contains a large amount of text, the input during the composition event process can cause the browser to layout, paint, and other processes. This process is slow for the browser itself, resulting in a poorer input experience.
This is something that the browser will do by itself during composition. It has to, since composition is changing the document.
ProseMirror will not try to delay editor state updates during composition. Trying to interfere with composition events will definitely not work—the browser needs to handle these normally for composition to work at all.
Activity
marijnh commentedon Jun 27, 2024
We want the editor state to track the actual composition state. Freezing the editor until composition finishes has lots of disadvantages (extensions will appear unresponsive, on Android composition often only finishes when the user moves the cursor away from a composed word, etc).
What kind of expensive redrawing are you seeing? The view update should generally be a no-op during composition.
fantasticit commentedon Jun 27, 2024
A document of 300000 words, then input four or five words at the end.
marijnh commentedon Jun 28, 2024
I cannot really make anything out in those scaled-down screenshots. Does this document perform well if you edit it as a plain contenteditable element? Where do the dev tools say the time is spent?
fantasticit commentedon Jun 28, 2024
When a document contains a large amount of text, the input during the composition event process can cause the browser to layout, paint, and other processes. This process is slow for the browser itself, resulting in a poorer input experience. Therefore, I believe that changing the editor state after the composition event is completed can improve the user experience (at least on the PC side).
If I want to update the editor after the composition event is completed, could you give me a suggestion on how to modify the
prosemirror-view input.tscode?For example, I tryied to hung a virtual node on top of the editor node to receive composite events.
marijnh commentedon Jun 28, 2024
This is something that the browser will do by itself during composition. It has to, since composition is changing the document.
ProseMirror will not try to delay editor state updates during composition. Trying to interfere with composition events will definitely not work—the browser needs to handle these normally for composition to work at all.