Screen jumping, when multi user is editing - image_

[amovsisyan]

This issue is unique.

• [X] I have used the search tool and did not find an issue describing my bug.

Operating System of DocumentServer

Docker

Version information

v8.2.2

Expected Behavior

Not have screen jumps during the cases which are described in the actual behavior.

Actual Behavior

Hello team we found some screen jumping scenarios during our usage of onlyoffice 8.2

First scenario is happening when there are media (images) and tables Whenever USER 1 cursor stands within the table (and within one page view, not within multi page view) and USER 2 makes changes on top (or may be in any place), USER 1's screen jumps (approximately 1-2 page up) Please find attached video with images

Second scenario , when there are page breaks - jumping effect only happens when we encounter a page breaker, when some content needs to move from one page to the following one (regarding of where in the doc). Please find attached video as well

Possible root causes might be different cases , than it is described, but at least, with this steps you can reproduce issues.

Attaching documents as well , that you can have the same test scenarios

Reproduction Steps

No response

Additional information

test screen jump - breakdown.docx

https://github.com/user-attachments/assets/1828a1fb-88d4-4f5e-b91d-dce65e5364e3

https://github.com/user-attachments/assets/263ddf68-1e4f-4929-b83b-b9fe8fe42827

test screen jump - images.docx

[amovsisyan]

@ElenaMaaya any kind of updates/estimations/status changes related to this issue ? Were you able to reproduce the issue ?

Thanks

[ElenaMaaya]

Hello @amovsisyan .
Thank you for your attention to our product! I think these are two different issues. I can confirm that the issue in "test screen jump - images.docx" exists. I have created bug 72234 for this issue.

Unfortunately, I can't reproduce the problem from "test screen jump - breakdown.docx" on Windows 11 DS v.8.2.2.

Please create a new issue for problem in file "test screen jump - breakdown.docx". And please, press the "Nonprinting characters" option in the Home tab in the test file and shoot a video again. Please put this video in a new issue.

Thank you for your understanding and help! We try to follow rules one issue - one bug.

[amovsisyan]

As it was torturing me so much, I looked into the code and tried to manage some fixes.

As you guys know a lot more than me from code, can you pls double check the fix on your side and make sure that?

1. this fixes the current problem
2. does not make any other problems

Here is a PR from my fork

tagging: @Rita-Bubnova @ElenaMaaya Thanks

[toad]

I have a reasonably reliable way to reproduce this if anyone is interested:

• Create a document with a table of at least 2 rows and 2 columns
• Put more than one page worth of text in row 1 (right cell)
• Write text constantly to the second row in browser A (e.g. using a bash script with xdotool)
• Now open the same file in browser B (different user, different browser; different computer/focus makes no difference)
• Start at the top and try to scroll down with the scroll bar
• The scroll bar, and the view, get reset to the top, or at least jumps up, every time the other browser adds a line

The practical issue for us is that if somebody is typing in a document, it is impossible to scroll past them (it keeps jumping back up); this is particularly problematic for using OO to take meeting minutes.

Also, I will try your patch!

[toad]

Update: @amovsisyan 's patch works correctly as long as I only use the arrow keys. However, if I try to navigate with either the scroll bar or the page up / page down buttons, sooner or later (I think if movement coincides with the typing end adding a newline) the view jumps up to somewhere near the top (even though the selection does not move). I think our problem is reasonably close to their bug report; we previously reported it as #2826 .

[toad]

@amovsisyan @Rita-Bubnova I've created an improved patch for this, based on the work by @amovsisyan . That fixes about 99% of the issue for me.

https://github.com/ONLYOFFICE/sdkjs/pull/4850

However even with the patch, the scroll bar can become disconnected from the mouse pointer. That is, if you are scrolling downwards, while somebody is typing, sometimes the mouse pointer moving doesn't move the view, and this accumulates, so the mouse pointer ends up well below the scroll bar toggle.

I suspect that's actually a separate bug though.

Without the patch, it is unusable for taking minutes, due to the jumping bug described above (trying to scroll down keeps jumping back up as long as somebody else is typing), which is a major concern for my organization.

I note that @amovsisyan has in fact signed the CLA, but has then changed their email address used for commits.

[manicmarvin]

This family of bugs related to viewport sync and simultaneous edits is a huge obstacle to getting everyone in our org to stay on NC/OO. Any change of merging these patches into stable releases?

[ElenaMaaya]

This family of bugs related to viewport sync and simultaneous edits is a huge obstacle to getting everyone in our org to stay on NC/OO. Any change of merging these patches into stable releases?

Hello, @manicmarvin! Thank you for bringing this issue to our attention. Our development team is actively working on resolving these issues.

[samuk]

Would you expect this to be resolved in ONLYOFFICE Docs 9.1.0? Should I open a new ticket for the same issue in that version?