Hi all. Because the prosemirror-view package has seen some significant churn in the past weeks, I’ve put out a beta version for the next release. While most of the bigger changes are cleanups that improve the structure of the code, in a codebase like this, that interacts in subtle ways with a lot of hard-to-predict browser behavior, it’s hard to be sure nothing regressed. I encourage users to at least run their test suite with the beta version, and let me know if it broke anything.
The main changes in this upcoming version are:
I overhauled DOM selection tracking to make it less ad-hoc and avoid superfluous reads from the native selection.
Mouse selection is no longer deferred to the browser’s native implementation, but handled by the library. This should get rid of the whole class of issues where drag selection mysteriously aborts (especially on Chrome) and all the fragile hacks to work around that. It also means selection probably works subtly differently now in some edge cases, and I may have introduced regressions.
The way the view tracks damage done by DOM changes to its DOM tree has been redesigned to be more fine grained. This should mostly mean there will be less unnecessary redraws of nodes, but again, might have regressed something.
The code targeting Internet Explorer has been dropped from the library. Starting this version, Internet Explorer is no longer a supported browser.
I’ll release this as a regular version in a week or so, if no unfixable issues are found.
Thanks for the beta! I found a few regressions and behavior changes. I’ve created minimal reproductions for each case. It seems that I cannot upload videos directly to discuss.prosemirror.net, so let me know if you cannot reproduce them.
A selection set right after focus() is lost
Click the button under each editor
Wait a moment.
Expected: the blockquote stays node-selected.
Actual (1.43.0-beta1): the selection turns into a TextSelection and ProseMirror-selectednode is removed. Happens in Chrome and Safari.
Double-click word boundaries differ from native
Double-click don't.
Double-click snake_case.
Expected: the whole word is selected, as with native selection.
Actual: only don / snake (or case) is selected.
The first click into an unfocused editor puts the cursor in the wrong place (Safari)
Open the page in Safari.
Click once in the middle of the second paragraph of the beta editor.
Expected: the cursor is where you clicked.
Actual: the state selection is updated, but the DOM cursor stays at the start of the editor. In our app, Chrome shows this too, and the state then follows the DOM back to the old position.
Clicking a non-editable control focuses the editor
Create a node view with a contenteditable=false button and no stopEvent.
Click the button while the editor is not focused.
Expected: the editor stays unfocused, like in 1.42.9.
Actual: the mousedown handler focuses the editor.
(this is a behavior change but not necessarily a regression)
handleClick now runs on mousedown instead of click
In 1.42.9, handleClick ran on mouseup, and only when the mouse had not moved (no drag selection). In 1.43.0-beta1, it runs as soon as the mouse button is pressed. This has some effects:
You cannot start a drag selection on a link.
When the handler returns true, the whole gesture ends. A user who wants to select the link text opens the link instead.
You cannot cancel a press.
A native click fires only when the press and the release land on the same element, so moving away before you release cancels it. Now the handler has already run when the button goes down.
I’ve pushed some further patches, and tagged a 1.43.0-beta2 that should take care of these, except for the one with the non-editable button. That’s something your node view should handle in its stopEvent method. That has always been the case, but the new selection handling makes it more of an obvious problem.