# Prosemirror-view 1.43.0-beta1

**URL:** <https://discuss.prosemirror.net/t/prosemirror-view-1-43-0-beta1/9127>\
**Category:** Announce\
**Created:** [November 8, 2026, 9:43am UTC](https://discuss.prosemirror.net/t/prosemirror-view-1-43-0-beta1/9127 "2026-11-08T09:43:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![marijn](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/marijn/32/15_2.png) [@marijn](https://discuss.prosemirror.net/u/marijn)\
**Post date:** [November 8, 2026, 9:43am UTC](https://discuss.prosemirror.net/t/prosemirror-view-1-43-0-beta1/9127/1 "2026-11-08T09:43:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ocavue](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/ocavue/32/2239_2.png) [@ocavue](https://discuss.prosemirror.net/u/ocavue)\
**Post date:** [November 8, 2026, 11:04pm UTC](https://discuss.prosemirror.net/t/prosemirror-view-1-43-0-beta1/9127/2 "2026-11-08T23:04:26Z")

</div>

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](http://discuss.prosemirror.net), so let me know if you cannot reproduce them.

* * *

## A selection set right after `focus()` is lost

> **[prosemirror-view: selection set right after focus() is lost](https://issueset.github.io/reproductions/2026-11-09-pm-view-focus-node-selection/dist/)**

1. Click the button under each editor
2. 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

> **[prosemirror-view: double-click word boundaries](https://issueset.github.io/reproductions/2026-11-09-pm-view-double-click-word/dist/)**

1. Double-click `don't`.
2. 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)

> **[prosemirror-view: first click into an unfocused editor](https://issueset.github.io/reproductions/2026-11-09-pm-view-first-click/dist/)**

1. Open the page in **Safari**.
2. 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

> **[prosemirror-view: clicking a non-editable control focuses the editor](https://issueset.github.io/reproductions/2026-11-09-pm-view-noneditable-focus/dist/)**

1. Create a node view with a `contenteditable=false` button and no `stopEvent`.
2. 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)

* * *

---

<div class="post-metadata">

**Author:** ![ocavue](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/ocavue/32/2239_2.png) [@ocavue](https://discuss.prosemirror.net/u/ocavue)\
**Post date:** [November 8, 2026, 11:28pm UTC](https://discuss.prosemirror.net/t/prosemirror-view-1-43-0-beta1/9127/5 "2026-11-08T23:28:49Z")

</div>

## `handleClick` now runs on mousedown instead of click

> **[prosemirror-view: handleClick runs on mousedown](https://issueset.github.io/reproductions/2026-11-09-pm-view-click-on-mousedown/dist/)**

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.**

- **You cannot cancel a press.**

---

<div class="post-metadata">

**Author:** ![marijn](https://discuss.prosemirror.net/user_avatar/discuss.prosemirror.net/marijn/32/15_2.png) [@marijn](https://discuss.prosemirror.net/u/marijn)\
**Post date:** [November 9, 2026, 12:14pm UTC](https://discuss.prosemirror.net/t/prosemirror-view-1-43-0-beta1/9127/6 "2026-11-09T12:14:34Z")

</div>

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.
