Weird chrome 75 bug with scroll and focus

#1

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 ?
#2

I’m trying to reproduce it on glitch. Maybe the bug is related to the fact i’m making the body editable.

#3

At the moment the window scrolls back to the last focused node only if i scroll using mousewheel, not when i scroll using scrollbar.

#4

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.

#5

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.

#6

Hmm i don’t see this issue anymore. Can you check if https://github.com/ProseMirror/prosemirror-view/commit/379a5f743b1fd486551db8a4b9296f4a87b997b4 fixes it for you ?

Otherwise let’s compare our chrom(e|ium) versions: 75.0.3770.100 here.

I suspect the issue was more something like:

  • one of my nodeViews was updating itself (in a non editable zone)
  • prosemirror had a bug fixed by above commit that made it reparse the whole document on js-triggered DOM changes, thus changing the selection.
#7

@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.