UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36

Steps to reproduce the problem:
1. Open any page taller than the viewport.
2. Wait for the overlay scrollbar to fade.
3. Try to scroll to the 3/4 (or whichever) point of the page by middle-clicking 3/4 of the way down the right edge of the window.
4. Summon the scroll bar by twiddling a physical scroll wheel or pressing arrow keys.
5. Repeat #3 while the scrollbar is present.

What is the expected behavior?
At #3: scrollbar should appear; at both #3 and #5: page should scroll proportionally to the point clicked (as if the scrollbar had been dragged to that point).

What went wrong?
Nothing happened.

Did this work before? Yes Not sure; I've only noticed this in the last week or two.

Chrome version: 56.0.2924.76  Channel: stable
OS Version: Goobuntu
Flash Version: 

I think two things have changed here:

- Overlay scrollbar used to appear when hovering over the rightmost few pixels of the window.
- Middle-clicking in the transparent part of the scrollbar area (i.e. above or below the rectangle that represents the viewport) while the overlay scrollbar was active used to jump to that offset.  (Afterthought: this seems to be the same change as disabling the left-click behavior of jumping a fixed distance towards the cursor; but I never used that anyway).

Both of these changes are bad for anyone who doesn't have an infinite-scroll mouse (e.g. Logitech MX Revolution) or want to develop RSI.  The remaining methods of scrolling long "distances" are varyingly imprecise, slow/tedious, or straining:

- Mash PgUp/PgDn until near the desired offset, then mash Up/Down to fine-tune.  This is repetitive, slow, and impossible to scroll more precisely than the scroll size of the Up/Down keys.
- Middle-click in the page and move the mouse away.  Seemingly Windows-only, and very prone to overshooting and needing to correct since the mouse displacement controls velocity rather than offset, and hard to get a precise offset for the same reason.  (By the way: please don't read this as a request to enable it in Linux, as IMO it's nearly useless at best / annoying at worst, and would break the middle-click behavior of inserting the X selection, which is something that has a history of breaking on its own).
- Scroll repeatedly with the scroll wheel until at the desired offset.  For traditional clicky scroll wheels, this is exactly as imprecise as the Up/Down method since one click of the scroll wheel == one press of Up/Down.  It's also the most strenuous choice, since it involves repeatedly rolling a finger over a scroll wheel (fully extending and then fully curling it).  It's also much slower than PgUp/PgDn.
- Twiddle the scroll wheel to summon the scrollbar, target the very narrow and often very short scroll bar (hurry, you only have 1.5s before it fades!), left click and drag to the desired point.  This is as precise as the now-broken middle-click, but requires an unintuitive action (twiddling the scroll wheel) to enable the gesture, and then requires the user to target a very small area on a short time limit.

By comparison, to scroll long distances with middle-click: target anywhere on the right edge of the window (usually ~infinite area since overshooting stops at the edge of the display); middle-click and fine-tune by moving the mouse vertically.

Summary: Traditional scroll wheels and trackpad gestures are terrible at scrolling long distances, and the scrollbar was the only reasonable way to do so.  Now it's broken.