Do not cause scrolling for collaborative edits

1

When I put my cursor at a document position which is scrolled out of view and someone edits the document using the collab module, the editor scrolls to my cursor position as soon the collaborator’s steps are applied. Is there any way to prevent this behavior? I looked at the collab module code, but it doesn’t call scrollIntoView on the transaction it generates inside receiveTransaction so I’m not sure what is causing the scroll.

2

Not sure if this is your problem, but 0.17.0 had a bug where view.focus() would cause a scroll. Upgrade view to 0.17.1 and see if the problem persists.

3

Interesting, I did not know about the 0.17.1 update yet. Unfortunately the problem still persists after upgrading to 0.17.1.

4

The problem, it seems, is that ProseMirror has to reset the browser selection after it updates the document, and the browser is taking this as a cue to scroll the newly set cursor into view. Some workaround where ProseMirror immediately resets the scroll position back to the old place might be possible (though it feels quite kludgey). I’ll look into it when I have time.

1 Like
5

Thanks for looking into this!

6

I’m running into this issue as well - @marijn I would be happy to try to take a look and fix this - but could you provide a pointers on where to start poking around the code?

Thanks!

7

I have a branch where I have a half finished fix for this, I’ll try to push a patch soon

5 Likes
8

prosemirror-view 0.17.6 should behave better here – it explicitly resets the scroll position after transactions that touch the DOM selection but didn’t have scrollIntoView called.

2 Likes
9

Thanks for posting this patch! It’s working great for us - but we ran into an error in resetScrollPos on this line:

var newRefTop = refDOM.getBoundingClientRect().top

Uncaught TypeError: Cannot read property 'getBoundingClientRect' of undefined

In our setup we collaboratively load the document as the very first thing we do, so I wonder if that’s triggering this somehow. I’ll dig in and provide more details if I figure it out.

10

Ah, yeah, that would happen when your document is empty. This patch should help

1 Like
11

Hi,

I’m not sure if this is related to the recent changes on the scrolling discussed in this topic, or if it’s unrelated (sorry if this should be another topic). When working with a big document which span out of the viewport, it seems that updating the state trigger a scroll back to the top of the editor view. Is this intentional, and if so, is there an option to prevent this behaviour ?

To give you some context, we’re working with an history that stores old versions of a document, serialized in json. When the user wish to see an old version, we’re calling

let docNode = pilotSchema.nodeFromJSON( docJSON );
let newState = EditorState.create($.extend({
    doc: docNode
},
stateOptions));
// Apply the new state to the editor view
pmView.updateState(newState);

The user then lose the context where he was working because the viewport scroll to the top.

Thanks, Thomas

12

Are you, by any chance, still on version 0.17.0 of prosemirror-state? That one had a bug that might cause this, which was fixed in 0.17.1. If that’s not the case, could you reproduce the issue to a minimal demo? I can’t get this to happen in my setups.

13

Here is the minimal demo : https://dl.dropboxusercontent.com/u/71131776/prosemirror-scroll.zip You can scroll to the bottom of the page, click the button, and it’ll scroll back to the top. The deps are :

npm install prosemirror-example-setup prosemirror-model prosemirror-view prosemirror-state prosemirror-schema-basic ±- prosemirror-example-setup@0.17.0 | ±- prosemirror-commands@0.17.1 | | -- prosemirror-transform@0.17.0 | +-- prosemirror-dropcursor@0.17.2 | | – prosemirror-view@0.17.7 | ±- prosemirror-history@0.17.2 | | -- rope-sequence@1.2.2 | +-- prosemirror-inputrules@0.17.0 | +-- prosemirror-keymap@0.17.0 | | – w3c-keyname@1.1.5 | ±- prosemirror-menu@0.17.1 | | -- crel@3.0.0 | +-- prosemirror-schema-list@0.17.0 | +-- prosemirror-schema-table@0.17.0 | – prosemirror-state@0.17.1 -- prosemirror-schema-basic@0.17.0 – prosemirror-model@0.17.0 `-- orderedmap@1.0.0

14

Ah, I only now realize that you’re creating a completely new state, rather than updating the old one. That will, conceptually, reset the editor to a completely new document, in which case it doesn’t preserve its old scroll position. If you want it to, you’re going to have to save and reset the scroll position yourself, since the editor has no idea which part of the new document might correspond to which part of the old document.

15

Ah I see, that makes sense. I’ll try to tinker with the state transforms to see if I can replace the whole content within the same state.

Thanks !

16

Great! I just tested this and was not able to reproduce the issue anymore. Thanks for fixing this :slight_smile:

17

Has anyone seen something like this in recent versions? We are suddenly now seen uncontrolled scrolling when collaborators edit the document. I haven’t yet started debugging what is happening exactly.

18

Ok, I have tested this some more. It looks like this happens when a collaborating author adds new content further up in the document.

19

Can you reproduce this in the collab example? I am not seeing it.

20

We’re on the latest version (1.0) and I can’t reproduce any uncontrolled scrolling in a collaborative setting.