Just thought I'd point out it's not the same issue as https://phabricator.wikimedia.org/T220174. The issue is very different to the video provided there, it occurs on desktop, does not occur in reading mode and it did not occur that early. But who knows, they may be linked.

This issue has never been fixed. Adding some additional confirmatory details to the issue. @Aklapper

@matmarex @JTannerWMF Someone needs to hear about this. It's driving me insane.

I can reproduce this. Note that you have to press, hold, and let go of the button really fast and while moving the mouse to trigger the problem. I initially couldn't reproduce it because of that (and also, I didn't even know you and press and hold the middle mouse button, I always click it once to enter the scrolling mode, then click again to exit it).

What happens here is:

1. The initial middle-press places the text cursor, the same as if you left-clicked. I'm not sure if this is expected. I think this is a native browser behavior rather than cause by our code.
2. The browser scrolls the page to follow your mouse cursor.
3. A few milliseconds after the initial press, we try to scroll the text selection/cursor into view. This is the same behavior that e.g. scrolls the whole infobox into view if you click to select it after scrolling down the page.

I think we'd need to do one of two things to fix it:

• Prevent middle-clicking from placing the text cursor
• Don't scroll the text cursor into view during middle-click scrolling

…But I'm not sure if it's actually possible to do either of them. This would take some investigation.

For completeness: on Firefox and IE, middle-clicking the text of the page doesn't place the text cursor, and so this issue doesn't occur on those browsers. So this is a Chrome bug, I'm not sure if we can work around it.

However, on every browser, middle-clicking a focusable node (like a template, floating image, references list) does place the cursor. I can reproduce the issue on them if the initial middle-click happens to land on e.g. a references list. So this part is a VE bug.

I filed a bug in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1053757

@matmarex Thank you for all this additional info. I had in fact drafted up a Chromium bug report before commenting on this until I tested it on an Chromium version older than the issue and confirmed what I thought, that it was triggered by a VisualEditor update rather than a Chrome one.

You are probably right about it being a native browser behaviour; see here: https://meta.wikimedia.org/wiki/Talk:Community_Tech/Who_Wrote_That_tool#I_can_immediately_think_of_two_things_to_improve_this_tool

And wow, I can't imagine not using middle-mouse drag to scroll.

That issue I just linked seems to be unrelated but very similar. Either way, I filed a bug report for it too since it was pissing me off: https://bugs.chromium.org/p/chromium/issues/detail?id=1054854

So, the issue here seems to be a native Chromium behaviour from before 2018 that was only triggered by an update to VisualEditor in June 2019, whereas the issue I linked is a Chromium behaviour that was instigated on 11 September 2019.

EDIT: I just tested and this issue even occurs in Chromium 40.0.2192.0 from 16 October 2014.

It's not a Chrome bug. The behaviour I describe in the original post is a VisualEditor bug.

The Chrome behaviour has always been that way. The VisualEditor behaviour only started in June 2019.

Go to any Wikipedia page, like https://en.wikipedia.org/wiki/DNA_methylation.

Paste "javascript:document.body.contentEditable='true';%20document.designMode='on';%20void%200" in the URL (don't forget to re-add the "javascript:") and press Enter.

Then try to reproduce the bug. You can't.

It only happens in the VisualEditor editing environment.

Just because the caret gets placed to the cursor in contentEditable environments in Chrome, doesn't mean that snapping behaviour has to happen.

Though I would agree with you that it's not expected that the middle-mouse button should place the caret. And I could also reproduce the issue in Firefox when dragging from an image or template.