The docs for updateState don’t mention scrolling behaviour, but I’m finding that every time I call updateState on an editor, it is scrolled into view, even if the editor is not currently focused.
Is there a documented way to prevent this behaviour, or is it intended, or a bug?
Ah - I just found this discussion: Prosemirror-view: scrollToSelection and resetScrollPos
…which leads to this patch: https://github.com/ProseMirror/prosemirror-view/commit/dcbf44a3981f299cf973c1eb1c678dc6d17ed02d
Unless scrollIntoView was called on the transaction that produced the new state, no scrolling into view should be happening. What kind of new state are you giving it?
It’s possible that scrolling is being triggered by using setSelection as well?
For testing purposes, I created a loop that simply resets a view with its own doc every 1000 milliseconds, so there is no change applied at all. Each time it runs I am scrolled back to the top of the page.
the code is roughly:
var prevState = pmView.state;
var newState = EditorState.create({
doc: prevState.doc,
schema: mySchema,
plugins: prevState.plugins});
pmView.updateState(newState)
(Is there something wrong with how I am creating the new state from the old one?)
I am trying my best to make sure nothing else is happening. In Chrome developer tools I made a performance recording while this loop was running, and the entire relevant call tree is:
Ah, you’re creating a completely fresh state. In that case, it can’t determine if scrolling should happen, since there’s nothing to compare, and it defaults to scrolling into view. Unless you’re somehow starting over with a completely new document, updating to a completely new state is probably not what you want—it’s more expensive than updating with a transaction, and you won’t get undo history support and such.
But defaulting to scrolling into view in this case is probably not the right call anyway. This patch changes that.
