Hi,
Using prosemirror-view 1.8.4 or 1.9.0, i updated to chrome 75.0.3770.18 this morning and now the editor keeps scrolling the window back to where the focus is, as if node.scrollIntoView() was called every second.
Does not happen in chrome 74.
I’m still trying to figure if this is a bug in my code or not. I tried tracing calls to:
window.scrollTo
Element.prototype.scrollIntoView
but i had no success (whatever is moving the window scroll is not calling that).
Any idea of to debug that ?
Chrome regressions around editable content would be nothing new. Let me know if you have a clearer view of what’s happening—and definitely report the browser bug when you have a way to reproduce it without ProseMirror.
Hi @kapouer,
we experience a similar issue in our servicenow platform. The internal admins have updated chrome to version 75, and since then and only in chrome we have the issue of “scrolling where focus is”.
The issue is somewhat hard to reproduce, but if you scroll and move the mouse at the same time you will get jittery scrolling for sure. If you click into a table, have the focus there, scroll and then move the mouse, chrome will scroll to the “last clicked table”.
In our application we have multiple <table role=“presentation”> and if you move the mouse from one to another, chrome tries to scroll the table into focus (as if you have an #anchor). We have no “editable” attribute anywhere, but elements are draggable with attribute “dragpart”.
Have you had any success diagnosing this problem? I can’t find any thread, bug or something in the patch notes that hints to the source of the problem.
@GordonMohrin: we’re also encountering the save problem.
We could reproduce the bug by click print (or press “Ctrl + P”) to bring up the Print Preview dialog, then dismiss the Print Preview dialog, thus the editor will start to enforce the focus caret at the same scroll position.