New issue
Advanced search Search tips
Starred by 41 users

Issue metadata

Status: Duplicate
Merged: issue 567968
Owner: ----
Closed: May 2014
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Linux scroll bars pop back to starting position when mouse moves to the side

Reported by w...@igoweb.org, May 24 2014 Back to list

Issue description

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

Steps to reproduce the problem:
1. Go to web page large enough to need scroll bars
2. Grip scroll bar, and scroll to bottom
3. While still holding mouse button down, slide mouse sideways

What is the expected behavior?
Scroll bar should remain where it is as mouse slides sideways

What went wrong?
Scroll bar snaps back to where it was before you began scrolling

Did this work before? Yes Previous version

Chrome version: 35.0.1916.114  Channel: stable
OS Version: Ubuntu 14.04
Flash Version: Shockwave Flash 13.0 r0

This was added intentionally.  Issue 337919  was the discussion of the code that was added; this behavior is standard on Windows, but on Linux it is not standard and is very disturbing when you are not used to it.
 
Status: WontFix (was: NULL)
According to our Linux owner, Qt natively does snapback on Linux, so this is not so cut-and-dried as "not native on Linux".

Scrollbar snapback has a long history of debate in many products/forums (just do a Google search).  I realize that this means there are always going to be both defenders and opponents, and if we "just added an option" we'd probably reduce the amount of debate.  However, the benefit of such an option does not rise to the high level that Chrome's design philosophy requires.  So we have to make a call one way or the other.  For now, that call is to support snapback, as we think more benefit accrues due to use of snapback than harm, at least as long as the snap thresholds are sufficiently large that one isn't constantly triggering the behavior.

Comment 2 by w...@igoweb.org, May 24 2014

Thanks for your comments. I disagree but I see your point.

One thing that I think must be a bug: The snapback also happens when you move the mouse above or below the scroll bar, not just to the side. That means that if I grab the scroller, then yank the mouse to the top of the screen, instead of scrolling to the top as expected, the scrollbar whips up then snaps back to the bottom.

I don't have a Windows system to test, but is this expected behavior? I would expect it to snap only when the mouse moves to the side of the scroll bar (well, perpendicular to the scroll movement; on a horizontal bar I would expect snap to happy when the mouse moves above or below).

Comment 3 by timp...@gmail.com, May 24 2014

@2: I can repro that on Windows too. That does not seem to be the behaviour on Win's native scrollbars though (tested with Firefox).
Came here to report this scrollbar behavior as a bug. Very disappointed to find that this "feature" was added intentionally and marked "WontFix". 

PLEASE give us an option to disable the snapback, or let us configure the thresholds and set them high enough to effectively disable it that way.
I'd be curious what Qt applications your Linux owner has observed this behaviour with.   Given I've not seen it on any KDE applications, they may have a wrapper / modifier around this (presumably to align it with all the other GNU/Linux desktop environments).

I've got a tiny number of Qt-but-not-KDE applications (there simply aren't all that many of them out there) and note that none of them behave in this snap-back way either.

In any case, Qt is a small subset of the application suite on GNU/Linux distributions, so even if Qt snapped back by default, claiming compliance with the tiny minority of apps isn't really 'alignment with all the GNU/Linux users'.

Just put the option in somewhere.  Less people will be offended by the compromise than by the arguable degradation to Chrome's design philosophy.  As a bonus, lots of people will be made happier by having the option to maintain the original behaviour.

@3: Firefox doesn't use Windows native scrollbars.  Test using Windows Explorer and you will see that this is, indeed, the native behavior.

@5: Unfortunately, I don't have an answer to that question.  In any case, we're not going to add an option in order to placate people, as I noted in comment 1.
Cc: abarth@chromium.org
 Issue 378479  has been merged into this issue.

Comment 8 by pilki@google.com, May 29 2014

Can I ask what the "benefit accrues due to use of snapback" are? I don't see any.

I have KDE, no application behave that way. So now I have one application, chrome, that decided to not behave the same way as all the other. It's also not the case on Gnome.

I also tried on Mac, and the native behavior is to not have snapback. Are we going to impose on every OS the behavior of Windows and not use the native behavior? Why do we impose that on our users?

Comment 9 by lodato@google.com, May 30 2014

It doesn't make sense to me to implement the Windows "scrollbar snapback" [1] on Linux because that would be inconsistent with every other Linux application.  But, if you still want to go down that path, there are two problems with the way Chrome Linux implements it.

The main problem is that Chrome Linux not only has a "horizontal range" outside of which the scrollbar snaps back, but it also has a "vertical range" that is not present on Windows.  In the comment box on this page, try the following on both Win7 IE9 and Linux Chrome 35:
1. Type enough lines to get a scrollbar.
2. Resize your window so that it does not take up the full height of your screen.
2. Drag the scrollbar all the way in both directions.

On Win7 IE9, the scrollbar stays dragged no matter how far vertically the cursor is from the scrollbar, even if that is outside the window.

On Linux Chrome, the scrollbar only stays dragged if it is within about 10 pixels, even within the same window!  This makes it VERY difficult to use, and I imagine this is the main source of frustration that everyone has been experiencing.


The second problem is that the horizontal range on Linux Chrome is about 7/8 the width of the Windows horizontal range.  This exacerbates the problem, because the snapback behavior triggers much more frequently for Linux Chrome users than it does for Windows users.


[1] http://www.red-bean.com/kfogel/scrollbar-redux.html
Chaps, I think you've missed the point.  pkasting has made it clear - there'll be no 'placating' (or what we may call fixing) this problem.

The behaviour that you grew up with is no longer applicable, and you must adapt to the Microsoft Windows behaviour (both in terms of snap-back, and in terms of no course for redress).  The only alternative is one small config button somewhere that allows you to use the application the same way you've always used it, and, well, come on now .. that's just ugly and totes unworkable.

If that config button was there it would a) imply that the developers made a mistake by unceremoniously changing this in the first place, and b) ensure that every chrome/chromium user in the universe would flip to using IE overnight.

Aside -- I note with great sadness that the latest set of updates in Debian unstable has brought this unwanted change to chromium (previously it was just chrome).

I recall with even greater sadness that this feeling of total helplessness with regards unwanted, non-useful, non-optional, non-negotiable changes was what led me to become a committed user and advocate of Debian and KDE back in 1999.


This description of reverting to earlier versions may be of use to Debian (and family) users.  I'm posting this to bugs  #337919  and  #377191 

Grab copies of v34 from, variously, depending on your distro / package:

http://mirror.pcbeta.com/google/chrome/deb/pool/main/g/google-chrome-stable/
http://mirror.pcbeta.com/google/chrome/deb/pool/main/g/google-chrome-unstable/

and 

http://snapshot.debian.org/archive/debian/20140531T221504Z/pool/main/c/chromium-browser/

(you may want to grab the matching chromium-browser-inspector package - check your current installed package list)

apt-get remove the existing v35 or later packages.  Then install the v34 debs.  If you're happy to lock that in, you can then run "apt-mark hold google-chrome-unstable" or "apt-mark hold chromium  chromium-inspector".  Note that this obviously means you won't get security patches for these packages.

Also note that v34 resolves both the retrograde snap-back and single-click-selects-the-whole-URL (on GNU/Linux) bugs.

 Issue 382852  has been merged into this issue.

Comment 13 by marja@chromium.org, Jun 10 2014

I tried to google what's the reason why the snapping is a considered good. The reasons I found ( http://www.red-bean.com/kfogel/scrollbar-redux.html , http://www.reddit.com/r/chrome/comments/1uprv3/chromes_scrollbarhelp/ ) were 1) it's possible to go look up something in some other part of the document, and quickly go back to the previous location 2) comparing two portions of a large document.

Are these use case we want to support (with the cost of scrollbars snapping back when the user doesn't want to)? Chrome has previously steered away from rare power user use cases towards making the average, not-necessarily-very-computer-savvy user happy.

Am I missing something obvious? Is there some other big advantage of snapping? Or is this more about being consistent with what the platform implements (or consistent across platforms) than the feature itself?

Comment 14 Deleted

@1 "According to our Linux owner, Qt natively does snapback on Linux, so this is not so cut-and-dried as "not native on Linux".

I don't know about Qt, but I've never seen a single scrollbar do snapback on Ubuntu, so that's wrong.

But you're right, this is not cut-and-dried as "not native on linux", this is cut-and-dried as "plain wrong and totally demential".

The behavior is plain wrong and the most sensible thing to do would be to remove even in Windows where it coincides with the "native" OS behavior. If an OS introduces a demential behavior, should Chrome necessarily adopt it? Not. 
As an exapmple of this: when Ubuntu introduced the demential overlay scrollbars (which fortunately are opt-outable), THANK GOD Google Chrome didn't adopt them, nor did any other browser. At least browsers have been saved from that disaster.
However, I don't care about windows. Go keep the ridiculous behavior on Windows if that makes Windows users happy (being accustomed to an absurdly wrong behavior), but let alone users of other OSes.

Now, regarding the fact that this behavior is wrong (regardless of OS-nativeness).
The fact that there's been "a long history of debate" doesn't mean that it's questionable. People debate about a lot of obvious thing. The world is full of idiots. So, the fact that there has been debate doesn't necessarily mean that both sides are reasonable and that it's a matter of personal taste. If you state that this is the case (i.e., both behavior are reasonable and it's a matter of personal taste), the existence of debate is not a proof, you have to name AT LEAST A VALID REASON why the snapback behavior may be desirable (since the obvious reasons why it is not desirable have already been mentioned by everybody).

@13 did that: he found the one single argument (use cases (1) and (2) in @13 are actually the exact same thing) in favour of snapping . Which, frankly, is pretty weak. Go try that. Try to use snapping in the way described. See what I mean? When you move back to the scrollbar area, you'll certainly deviate a bit on the Y axis, so you don't go back to the exact position anyway. Plus, if you accidentally release the mouse button for a moment, you're screwed. So that's not that powerful either. And there are plenty of other ways to design and implement a solution for that (rare, definitely non-avarage, but interesting) use case, even much better.
So, that argument is discarded, and it is the ONLY one that has been given so far in defense of snapback that made the least amount of sense.

Also note that does NOT apply to "vertical snapback" (i.e. snapback when you move too far to the top or to the bottom), think about it: it does not.



Anyway, there is one trivial, easy thing you could do to relieve the pain you're inflicting us with this demential behavior: it would be one-minute work and almost everybody would be happy: WIDEN THE AREA within which the bar does not snap back, which is INSANELY NARROW.

Comment 16 by Deleted ...@, Jun 12 2014

@1 "According to our Linux owner, Qt natively does snapback on Linux"

I have never seen snapback anywhere on Linux, and not on any other Unix platform either. I can't rule out that it exists *somewhere*, but I've been using these for 20 years now, and so far Chromium seems to be the only application with this behaviour.

Inconsistent UI behaviour is not good. Please roll back.

If you refuse: Will the Windows behaviour be forced on Mac users, too? (Just curious if you are hell-bent on anatgonizing everyone)
Snapback is horrible, it has annoyed me multiple times every single day since chrome 35.
1. You have to stay within a certain invisible area. - I personally do not keep an eye fixed on the mouse pointer while scrolling and reading long texts.
2. No more quick scrolling to the top - you will certainly overshoot the invisible area and snapback will get the best of you.

I'm shocked to find this huge design idiocy as "wontfix". Google you dissapoint me.
Obviously Google has been infiltrated as well.
By the way I have recently tried a couple of Qt-based applications on Linux (namely qpdfview and Qt Creator), and:

@1 "According to our Linux owner, Qt natively does snapback on Linux"

that's bullshit. It doesn't.


Comment 19 by lodato@google.com, Jun 21 2014

I'll say it again (see #9).  Most of the angry complaints will go away if you just extend the vertical range infinitely (and preferably extend the horizontal range by a bit, too).
If by "a bit" you mean like 300-500%, yeah.

Comment 21 by w...@igoweb.org, Jun 21 2014

I would disagree that expanding the limits solves the problem. Either the feature is good or bad, making the bar so wide that it hardly ever has any effect is bad for both cases.

I agree with earlier posters, whoever said that Qt under Linux has these scrollbars was wrong. It doesn't. Among major Linux apps, only Chrome has this behavior. Chrome should hold to its policy of fitting in to an environments native UI and ditch the snapback scrollbars.
Nobody said that expanding the limits solves the problem, but it can alleviate it significantly at 0 cost.

Expanding the vertical limit infinitely would be a bare minimum requirement even if one considered the "feature" good, because snapback when exceeding vertically makes no sense, under any circumntance, even under the assumption that snapback makes sense (it does not even support the convolute "quickly jump forth and back to two given points in the page in order to compare them" use case).

The "feature" is wrong, and there's no discussing that, but given that people at Google for some reason do want it (apparently because they chose the one operating system in the world that has it, Windows, as the model), the horizontal area IS insanely narrow, so also widening it horizontally is another bare minimum requirement.

Obviously the sensible thing to do is to remove snapback completely, but while we wait for that to happen, widening the area would turn a usability killer into a minor annoyance.
 Issue 388884  has been merged into this issue.
"According to our Linux owner, Qt natively does snapback on Linux, so this is not so cut-and-dried as "not native on Linux"."

Your "Linux owner" has probably switched his Qt theme for a Windows theme. Then Qt implements the horizontal constrain as expected. Any other platforms theme let users scroll freely in any direction. (You can test it easily: e.g. "google-earth -style windows" (constrains) or "-style plastik" (no constrains))

(For your original comment, it sounds that you believe that non-windows users insists just to annoy you, but that's not correct: it really makes browsing unusable if scroll-bar stop suddenly for no (expected) reasons)
This misfeature really does make chrome unusable, and I am sad that I will no longer be able to use it. 

Can anyone point me to the code that changed?  It would be useful to have a patch that fixes this bug which could be applied by those who want standard Linux/Qt behavior.  Our perhaps a fork. 
Cc: -abarth@chromium.org

Comment 27 by timp...@gmail.com, Jul 4 2014

(#24) I just tested that in a random Qt application (kwrite -style windows). The style of the bar changes too, which makes it in practice look like some sort of Windows emulation. Never seen any application use them by default (if it is even allowed by per app basis).

If this "Qt does it natively" claim is really about the above option... did this this actually play a role in the decision to enable this on Linux? Don't tell me so.

And I actually like the feature itself, always missed it from Windows, but the response to this issue has been pretty appalling.

Comment 28 by torrey@google.com, Jul 8 2014

Just a "me too" comment: I also thought this was a bug, and still do. If the Chrome designers insist on making this change, it should be Windows only.

Comment 29 by j...@wildlava.com, Jul 8 2014

Agreed. BTW, has anyone made a patch to disable this new behavior? I am in
the process of building from source now and am about to investigate where
this change was made so I can revert mine to a sane state in Linux, but if
someone has done this already, it would save me a bit of detective work.
When I have success, I'll post back here as well. If there is a better
place to have this discussion, please advise (e.g. is there an open forum
topic?).

Comment 30 Deleted

Comment 31 Deleted

Comment 32 by Deleted ...@, Jul 10 2014

Thanks, v34 will be my last version of chrome then.  I even had trouble scrolling this thread without chrome snapping back.  I'm slightly disabled, but I'm sure the windows-centric behavior is more important than me.

Comment 33 by wabor...@hemna.com, Jul 11 2014

Wow this is epically bad behavior for a scroll bar and it drives me nuts.  Guess it's time to fork Chrome so we can get a sane behavior back.

Comment 34 by j...@wildlava.com, Jul 11 2014

I posted this on the other "main" issue (#337919). If you build Chromium from source, this patch will disable the behavior on Linux and MacOSX. I'm currently working on an Arch Linux package (AUR) that incorporates this patch on top of the latest Chromium.

diff -Nurp a/content/renderer/webscrollbarbehavior_impl_gtkoraura.cc b/content/renderer/webscrollbarbehavior_impl_gtkoraura.cc
--- a/content/renderer/webscrollbarbehavior_impl_gtkoraura.cc   2014-07-09 20:00:44.021123448 -0600
+++ b/content/renderer/webscrollbarbehavior_impl_gtkoraura.cc   2014-07-09 20:00:09.334139089 -0600
@@ -25,6 +25,13 @@ bool WebScrollbarBehaviorImpl::shouldSna
     const blink::WebPoint& eventPoint,
     const blink::WebRect& scrollbarRect,
     bool isHorizontal) {
+
+  // Disable snap-back behavior on Linux and MacOS because it is
+  // inconsistent with standard/native scrollbar behavior on
+  // these platforms.
+  #if (defined(OS_LINUX) || defined(OS_MACOSX))
+  return false;
+  #else
   // Constants used to figure the drag rect outside which we should snap the
   // scrollbar thumb back to its origin. These calculations are based on
   // observing the behavior of the MSVC8 main window scrollbar + some
@@ -42,6 +49,7 @@ bool WebScrollbarBehaviorImpl::shouldSna
 
   // We should snap iff the event is outside our calculated rect.
   return !noSnapRect.Contains(eventPoint);
+  #endif
 }
 
 }  // namespace content

To all devs, please do not ignore comment #9. I can guarantee that this is the main issue here for most Linux users. Even though snapping back when moving the mouse horizontally is non-standard behavior, having it snap back when scrolling vertically is ridiculous. This is also behavior that is NOT present in Windows.
chrome_scrollbar.ogg
83.9 KB Download
Two updates here.  (Cross-posting this on  bug 337919  as well.)

We continue to try and tweak behavior based on feedback.  There are two changes for Linux users to try and decrease the number of times this triggers unintentionally:

*  Bug 388322  removes off-end drag canceling for Linux entirely, meaning you should be able to scroll off the end of a document and not have the scrollbar snap back.

*  Bug 397359  (in review) ensures that the off-side slop area is as large for Linux as it is by default for Windows.  For most people, that should mean the overall slop area is about 32 px wider, which should be helpful in reducing the number of times this triggers accidentally.

Hopefully, the combination of these two changes should at least reduce the frustration some of you are experiencing.

Comment 38 by j...@wildlava.com, Jul 26 2014

@37, thanks for continuing to listen to Linux users and try to make things better, but why not just disable snap back completely for Linux? That would eliminate, not just reduce, the frustration. No other Linux apps do this, so Linux users, as we've seen here, will find it annoying, confusing, and not useful. Disabling is trivial in the code. I've done it on my own builds and am happy, but I would be happier if the main-line code were also fixed.
Snapback is unintuitive and therefore user unfriendly.
If I scroll down a long page - It will always trigger unintentionally.

Why bother with emulating that behaviour when you could implement the cancel function in so many ways that you will be very unlikely to trigger unless on purpose?

For example, cancel by Escape button for Mac, and better cancel by right mouse click everywhere else.

Aside from that, make it less unintentional by marking the area, or make the feature toggleable.. So many ways to fix it and so little care.

Using firefox now after maany years with chrome, and what a bliss aside from the speed disadvantage.. (I have a powerful computer to counter that..)
Chrome is just soo flawed on Linux now in so many ways, like when it paste text with middle mouse without even pressing middle mouse in chrome but in another window to close the other window which just happen to be above chrome - or how about accidentally clicking once next to the new tab button suddenly maximize/resize chrome - or when shading chrome, chrome decide to suddenly move its window by 4 pixels which happen to be the border outside the screen area - etc. etc...


Also, annoying the powerusers is such a bad idea long term..

/Allan

Comment 40 by Deleted ...@, Aug 7 2014

I totally agree with everyone saying that the new scrollbar is ridiculously flawed, gives a bad user experience and the feeling of not wanting to use Chrome any more for it continuously punishing its user with that pop-back.

Seriously? 10px threshold for vertical overscroll? And about 5cm for horizontal? 

Comment 41 by xofon@google.com, Aug 8 2014

@11: Interesting to see someone suffering with the single-click-selects-the-whole-URL bug too. Does it have a bug number (or a fan club)?

Comment 42 by tot...@gmail.com, Aug 9 2014

Closed 'WontFix'? I guess that will soon be a 'WontUseChrome' for me before too long. Complete productivity killer and a total dealbreaker. Does anyone know of a good Fedora fork that does not have this terrible behaviour? (no way I am building from source every other day)

Like many of the comments above said (and many more elsewhere, just look at tickets 350750, 379030, 337919, etc), this new scrollbar is ridiculously flawed. It doesn't matter how many pixels you make the threshold, or how many toolkits made the same design mistake (in trying to provide a UI that works as expected on mswindows no doubt - usability claims are just window dressing, pun intended).
We are not using mswindows for many reasons and this is one of them, please don't make us feel like we are.
This behaviour is unlike what is present in *any* linux app that i've come across.
No current toolkit on *nix behaves like this by default, afaik.

One wouldnt put CTRL+N, CTRL+Q and CTRL-T commands into a MacOSX build instead of the META+N, etc. keys..

Why then is there the idea that making scroll-bar behaviour for *nix users is acceptable and the proper decision on this matter ?

The behaviour is so distracting to my browser-use, it's almost hilarious; i've started snorting coffee through my nose each time it happens just to keep from crying.

PLEASE FIX THIS (or make it a config-setting; like middle-mouse-cut-n-paste, single-select-url-bla.. etc.).

Comment 44 Deleted

Comment 45 Deleted

Comment 46 by stu...@gmail.com, Aug 13 2014

Awful, awful behavior. I've been using a Linux desktop full time since 1998 (KDE, then Gnome, now XFCE, though the apps I use are a smattering from all three) and this is the first time I can remember seeing this with any app.

I know some people like to use it to snap back and compare, but the problem is that the rest of us suffer for it. Before I could just relax and read my long web page -- now I have to add the cognitive load of keeping my mouse in some arbitrary vertical strip. Just so a few people can snap back and compare something? That's such a niche use it doesn't justify penalizing everyone else.

If I wanted this behavior, I'd use Windows. Please at least give us a checkbox.
Seriously, implement a proper snapback:


Hold/release right mouse button to undo scroll and compare buffers!


This way there will be no accidents! Not even for the snapback users, now they don't have to waste time placing the buffers pixel perfect.

Worried about the single button mouse users? - They're not even used to the snapback behaviour in the first place.

Google/chromedevs please..

Just do it.

/Allan
I don't understand how the preference of some of the Chromium devs for this feature and the data point that Qt seems to have this behavior according to the Linux owner results in the conclusion that it should be implemented universally for Linux. The Qt data point has been disproved by many of the above commenters, and no further evidence has been offered for it. 

Chrome has now become the only application on my Linux machines whose scrollbars have this behavior. Considering the diff indicated that this is a one-line code change and not a massive reliance on third-party framework, I don't see how the devs can maintain that the implementation of snapback on Linux is justified. 
Since this issue is closed as 'WontFix'.

If you are reading this, you might want to know that the party is over here: https://code.google.com/p/chromium/issues/detail?id=337919 :)

Comment 50 by timp...@gmail.com, Sep 18 2014

@49: And that bug just got its comments restricted.

"At this point further feedback on this issue should be left in the official feedback forums."

...if that doesn't mean the mess located at https://productforums.google.com/forum/#!categories/chrome , then I have no idea what it means. I doubt whining (rightfully) there makes much difference if it didn't make here.
Yeah, if they were being honest in saying "we're still open to feedback", they would have put a link to the "best place to gather it".

They obviously don't give a sh* about linux; we have already seen that when they dropped support for the Java plugin.
(but of course they can argue something like "That we don't take feedback into account the slightest bit doesn't mean we are not open to it")

Comment 53 by torrey@google.com, Sep 18 2014

Feel free to add comments to the user forum thread I created.  Who knows, maybe if enough people complain they will reconsider, or at least, explain their decision making.

https://productforums.google.com/forum/#!category-topic/chrome/give-feature-feedback-and-suggestions/linux/Stable/npQd3zbx9YM

Comment 54 by tot...@gmail.com, Sep 19 2014

I find it highly ironic that in the forum they are asking people to justify why not following the platform's default behaviour is important, when the bug that created this mess in the first place is exactly that: ensuring consistency but for Windows users. That says it all really.

The fact that this ticket
https://code.google.com/p/chromium/issues/detail?id=337919
has now been closed for comments and added "As to how we evaluate platform-native behavior, it's a judgment call." clearly shows that if a decision has been made, it is to give Linux users the finger. That, or just incompetence?
There is no such platform-native behaviour on Linux, never has been. This sounds like management speak for "we don't give a ****" without having to spell it out.
Thanks to dhw@chromium.org for pointing me here. This is exactly where I'd like to put my vote for a way (option or Linux-specific behaviour) to ban this, now /daily/, irritation. I don't have to put up with it anywhere else but in this (otherwise perfectly good) browser.

It's completely unsupportable and unarguable to want to have a scroll mechansim that flips back to where it was - when you take the mouse LESS THAN A CENTIMETRE ABOVE THE TOP OF THE SCROLLBAR!

Surely it would actually be quicker to fix this than to have all these discussions?

Please give me better behaviour in Linux or at least an option to enable that.

Thanks!

Duncan Cragg

Comment 56 by torrey@google.com, Oct 29 2014

To everyone who finds this bug:

It seems unlikely that Chromium developers care about this, and in fact, they have basically told us to shut up and quit complaining about their decisions here, because they do not consider this a bug, and They Know Whats Best.  Even though they also admitted that this was basically an arbitrary decision.

So while we wait for a truly open source, community-driven fork of Chrome to arrive, we have two options (other than Firefox):

First, there is at least one Chrome extension that mostly fixes the snap-back behavior, although it also introduces other scrollbar changes you might not want, and it doesn't work on every web site.  It helps for me, at least.  If someone finds or creates a better one, please post it in the help forum!

Try that extension out here: https://chrome.google.com/webstore/detail/scroll-style/lcfiapjcgfnalnpmgfoebehefdeekado

Second, we can complain and share tips and workarounds in the forum topic here:
https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!searchin/chrome/Scrollbars/chrome/npQd3zbx9YM/Hm2GtCs9TRAJ

Comment 57 by Deleted ...@, Jan 7 2015

Won't fix? Fair enough. Won't use. Removing this bit of weenie ware from my computer immediately after finishing this post.
I too find this one of the worst parts of using friends' Windows computers, so this is a show-stopper.

1. aptitude remove chromium
2. https://alternativeto.net/software/google-chrome/
3. ???
4. profit!

Comment 60 by Deleted ...@, Sep 25 2015

I would like pkasting (or another chromiumite) to be so good as to explain when this "snapback" behavior is ever actually useful. To date nobody has been able to give a rational explanation.

I consider this to be a sign of Windowsesque incompetence. Years ago Billy the Gates stated that users don't pay for bug swats. And the snapback bug remained in Windows. Chrome/chromium has seen fit to actually emulate irrational behavior. In like manner, pkasting says they won't placate users by making the scroll bar work in a rational manner.

In #57 I said I was going to remove Chrome/chromium. I did. In fact, I have reduced my use of Google products because of the mind set displayed here. Every now and then I'll check to see if Chrome/chromium is still broken. Opera works correctly. Firefox works correctly. Seems I don't really need three browsers.

Comment 61 by Deleted ...@, Nov 19 2015

I check in from time to time, stuck on Chromium 34, wondering if there will be a chance that new versions of chrome wont force awkward windows behaviors on me.  I see nothing has changed.   Has anyone forked chrome to get standard behaviors back?  Maybe we need a ppa for the new fork?
To #61, I've been using Opera for a couple of months now and couldn't be happier. It uses Chromium, so pages render just like Google Chrome and it fixes this bug and also has an option for MRU tabs (which hard-headed Chromium devs "WontFix" either https://code.google.com/p/chromium/issues/detail?id=5569).

Comment 63 by j...@wildlava.com, Nov 19 2015

I still do my own Arch Linux compiles when I upgrade. Easy, but takes a
while. I posed the patch on one of these issues, bit let me know if needed.

Comment 64 by wabor...@hemna.com, Nov 19 2015

I'm using Chromium 45 and I still see this issue.  It's absolutely awful.    I can't comprehend why anyone thinks this isn't a major bug.  

Comment 65 by Deleted ...@, Nov 19 2015

For Ubuntu users, it was shockingly easy to rebuild chromium-browser using these instructions:

https://help.ubuntu.com/community/UpdatingADeb

I suggest everyone simply rebuild the code base with all the Microsoft-nonsense removed since Google is ignoring this issue.

Comment 66 Deleted

Comment 67 by timp...@gmail.com, Nov 20 2015

#60: The use case when it is useful: think of a very long page, you're in the middle of it and want to quickly take a look at the top of the page while automagically returning to the exact position where you were. That's when it is useful. Rest of the time irritating.

Funny part is that I supported the idea of adding this in the first place, since originally it was removed from Windows too (the first versions of Aura were so incomplete), and probably one of the few things I sometimes seemed to miss from Windows, but then I changed my mind because the utterly ridiculous and repulsive way this bug was handled. I think the only nonsensical explanation given remains: "OS default way suddenly doesn't matter because this isn't the only time we've ignored it".

Comment 68 by Deleted ...@, Dec 20 2015

As an almost lifelong Windows Firefox user, I've never encountered snapback scrolling before I ventured into using Chrome. It's been at least a decade since I last used IE (does anyone use IE?) so at least for me, this is not a Windows-native behaviour.

It's stopped me using Chrome for years, until today, due to Firefox's latest update disabling an absolutely crucial extension for a site I use daily. I can't use the site without the extension, Firefox won't support the extension, so I'm here trying to wrangle Chrome again, and the snapback is just the most infuriating, miserable UI element I've ever ever come across.

I tried looking into a solution years ago, but nothing came of it and I went back to Firefox. I'm disappointed to find there's still no fix today. Maybe I'm the only Windows user with an issue, but if not an option to turn it off, then something to increase the margin for 'over-scrolling' would be miles better than a 'WontFix' verdict. Chrome is honestly unworkable for me with snapping scrollbars.
Scrolling with mouse @ 8200 DPI, on a 5K monitor.
Triggers this constantly.
Mergedinto: 567968
Status: Duplicate (was: WontFix)

Sign in to add a comment