I just upgraded to Chrome 57.0.2979.0 (about:system says "Developer Build 7f895d5eaee0e07855805fb3ae0a686799e9dc79 Linux") and encountered the new middle-click-to-scroll behavior. According to #522011 it looks like this landed with https://chromium.googlesource.com/chromium/src.git/+/87f287bbe619d07e907dc00f48e2a6ad725367c1.

NOTE! Fix this by disabling "Experimental Web Platform features" in about:flags. (I have no idea what else you're killing.)

What steps will reproduce the problem?

(1) Drag-select (don't ^C/^Ins) some text into the clipboard, either from Chrome or another application
(2) Verify that middle-clicking text areas in other applications will paste that text
(2) Middle-click into any part of a Web page that will accept text (<input>, <textarea>, contentEditable element, etc) in Chrome
(3) The middle-click event puts the middle-clicked target element into scroll mode and does not paste.

What is the expected result?

Middle-clicking in areas that accept input should paste whatever's in CUT_BUFFER0. This has worked on all Chrome Linux releases up to now.


What happens instead?

The new middle-drag-to-scroll code eats the middle-click button event and puts the middle-clicked element into scroll mode. Pasting never happens under any circumstances.

Also the cursor turns from a crosshair (text cursor) to a pointer (normal cursor) instead of something like the "fleur" X cursor font glyph, which for users who aren't expecting this behavior will prove baffling and make them think things are broken.


Please provide any additional information below.

Well, guys, you really got yourselves a good one here.

Long-term, graphics on Linux will be on Wayland et al and that'll be a totally new scene with new conventions, but right now there are only Intel drivers for Wayland/Mir, so anybody using desktop(ish) Linux with AMD/NVIDIA is on X11. X11 has used middle-click paste since its inception; the ^C/^Ins Freedesktop clipboard got bolted on some time later. Drag-to-select/middle-click-to-paste is a 30+ year old de-facto standard.

Chrome has supported middle-click paste since the Linux version was released, AFAIK.

But now, not only does middle-dragging scroll, middle-clicking puts the element that got middle-clicked into scroll mode until I click again. So if I middle-click on this textbox I'm typing into, that puts the textbox (as opposed to the page) into scroll mode. Drag-scrolling is fine, but middle-click-to-scroll completely replaces/inhibits middle-click-to-paste.

Furthermore, as I summarized above, besides the completely replaced functionality there's an extra issue: you're flicking back to the standard pointer (left_ptr) when in scroll mode, instead of displaying something like the "fleur" X cursor font glyph. I would never have expected the middle-mouse button to scroll on Linux, so without any sort of suggestive "you're in scroll mode" feedback it took me a good couple hours of fruitless middle-clicking to figure out the distinct characteristics of drag-scrolling and click-scrolling. This is because I keep off my touchpad when I middle-click so I can be sure my text goes where I want it to... so it literally took a good hour before I understood what was going on. That was fun. (This experience is now my reference example of a UX design fail.)

This was definitely working on 52 (I took a while to upgrade this time, I know) but I have a lot of confidence that any revision BEFORE https://chromium.googlesource.com/chromium/src.git/+/87f287bbe619d07e907dc00f48e2a6ad725367c1 has working middle-click-to-paste.

I'm not 100% on how to map Git revision hashes to Chrome versions (I don't actually think that's entirely trivial?) so I don't know when this feature landed; hopefully it isn't being released in the stable channel anytime soon! You're going to have a small pile of very angry users on your hands if you leave things as-is; I can definitely envision senior engineers loudly ditching Chrome over this. Some people *don't* use autocutsel and/to take advantage of the fact that there are multiple distinct clipboards in X11. (In my case I also use x2x for multi-machine control from one keyboard and mouse, and it only looks at CUT_BUFFER0. I don't use Synergy precisely because it handles the Linux clipboard so badly.)

Middle-click still pastes into the omnibox and I can still middle-click-"paste" into the new tab button, leaving Chrome rather lopsided in terms of how it responds to attempts to middle-click-paste.

Fixing this doesn't look easy because of Google's resistance to adding configuration options to Chrome; this would be the perfect candidate for an option. Unfortunately, I don't see any way for middle-click pasting and middle-click scrolling to coexist; they use the same UI semantics (responding to middle-click). One will have to give way to the other.

The first solution I thought of after I'd figured out middle-drag scrolling but before I'd discovered middle-click scrolling (it really took me quite a while to make heads and tails of this!) was to implement a threshold - move the mouse too far and you scroll, but straight clicks paste. I now realize this would completely kill middle-click-to-scroll on Linux though.

Another solution I thought of was to only scroll when eg the Ctrl key was held down, but that would introduce a behavioral inconsistency, and would make it impossible for webpages to capture Ctrl+Button2 events, which is generally something that can be expected across the board for all browsers right now.

I also wondered about pasting if there was something in the clipboard and scrolling if there wasn't, but that would likely lead to near-superstitious bug reports from people who aren't aware of drag-to-select.

For me, "Experimental Web Platform features" is firmly switched off, and I'll be restarting soon (I have 554 tabs open on 2GB RAM so it takes the Pentium M in this laptop a couple minutes to restart Chrome); hopefully I haven't lost any other cool features by doing this.