API edits cause the document to jump to cursor location

[sbevels]

This is an annoyance when reading the document. If your cursor is at the top of the document and you scroll down to the bottom of the document, you are immediately moved back up to where your cursor is at the top of the document when it is edited. This does not allow a user to read sections of a document without moving their cursor as they read.

Steps for Reproduction

1. Set cursor at the top of a long document
2. Scroll down to the the bottom of the document
3. Have another user edit the document.

Expected behavior:
User is not returned to cursor location if the user is not actively typing.

Actual behavior:
User is returned to cursor location.

Platforms:
Firefox, windows

Version:
1.1.5

[jhchen]

To clarify step 3 is use an API call? And more specifically an API call where source == 'api'

[sbevels]

Yes, I'm using the sharedb/quill example provided by sharedb. I'm calling updateContents(delta) when an op event is received. I'm not setting the source, but looks like it defaults to 'api' per the quill documentation.

[sbevels]

With this fix applied and my authorship module registered, it causes the cursor to jump to the beginning of the span when there is an API update in the middle of that span. Is it possible to move the check for source === Emitter.sources.USER from modify and add it to setSelection so that it doesn't call scrollIntoView() unless the source is a user? That fixes the issue for me.

[jhchen]

So you're saying setSelection(range, "api") is causing jumps?

[sbevels]

No, its actually not calling setSelection because source != Emitter.sources.USER in the modify function. I'm calling updateContents without a source so its defaulting to "api". It doesn't jump prior to the "only restore selection for user changes" commit. To fix the original issue about scrolling to the cursor on api changes, I think we still need to update the cursor location on api changes, just not scroll to the cursor, which is why I suggested not calling scrollIntoView from setSelection unless the source is "user".

[jhchen]

I see--it does make sense to not have the check in modify irrespective of what external modules do. It seems like it would make most sense to not scroll when source is silent?

[sbevels]

Yes, that makes most sense since setSelection is called with source === "silent".

[gdoudeng]

Hello how to solve such a problem @sbevels