Bug 24791 – Should have a preference to disable auto scrolling

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit Misc.

[Jon Honeycutt]

From discussion in bug #24722, WebKit should have a preference to disable pan-scrolling.

[Jon Honeycutt]

Not pan scroll, but auto scroll.

[Peter Kasting]

No client I know of will make use of this (certainly Chromium will not).  Suggest WONTFIX.

[David Levin]

(Already) Committed as http://trac.webkit.org/changeset/44276.

So for now it is fixed, but if chromium wants to revert it and other agree, feel free to do the WONTFIX thing on the revert.

[Peter Kasting]

The patch checked in does not add a preference that disables auto scrolling.  It adds a different preference.

[Peter Kasting]

Reverted r44276 in r44371.  The desired behavior for this bug, which I am not convinced any client wants (I don't think Safari or Chromium care, at least) is a pref to disable autoscroll entirely.  So I still suggest WONTFIX unless some client says they need this.

[Itai]

@Peter:

Hhhuhh? This bug is clearly an indication that some client says they needed this.
Chromium has three similar bugs too. See the discussions on any of those bugs to
see what the current behavior causes problems to some of our users. Clearly these
reports only exist because users have found something problematic. 

Disregarding these reports, the work and time it took to get a fix in is utterly
disrespectful, regardless of whether you see any purpose to it.

Users have reported problems and dismissing them is certainly the wrong approach.
The solution to the "accidental activation of autoscroll and loss of control"
problem is to implement a more efficient autoscroll mechanism which is springloaded,
as I implemented here as an option (as per the first WebKit reviewer's request).
This is a good solution because entering autoscroll is no longer sticky and users
cannot easily lose their location on a webpage. At the same time, autoscroll users
(those who intentionally use it) get to scroll and interact with the page in 3
actions (down, scroll, down) instead of 5 (down, up, scroll, down, up) which is
far more efficient. This is exactly what WK bug 21794 requested, as did one
Chromium bug.

Sorry to say but you have turned useful time for helping our users into a complete
waste. Since you got your revert in so fast, feel free to put this back in when
you are willing to solve user's problems.

(In reply to comment #5)
> Reverted r44276 in r44371.  The desired behavior for this bug, which I am not
> convinced any client wants (I don't think Safari or Chromium care, at least) is
> a pref to disable autoscroll entirely.  So I still suggest WONTFIX unless some
> client says they need this.
> 

[Peter Kasting]

Users request every possible thing on bugs.  The presence of requests for something does not imply we should do it.  If you don't understand or agree with this position please ask Ben Goodger or others on the UX team for justification.  It's a strongly held philosophy in Chrome and the entire team needs to understand why it's important.

[Itai]

This is WebKit here. Regardless, listening to users is important and if
you notice, this time, the bug was entered by someone at Apple. You closed
it without any valid reason other than the bug being here. Conversely to
what you said, we cannot close a bug simply because it _was_ filed.

I honestly think that people do not enter bugs to throw us off-track or
have us work on the wrong stuff. They enter bugs because they have issues.
While we may choose to not change things for various reasons, we cannot
simply dismiss these reports without a good reason.

[Peter Kasting]

This bug was entered by Jon because you filed bug 24722 and he was trying to accommodate you.  It is closed because Chromium, represented by you, was the only potentially interested consumer, but Chromium (represented by me on behalf of Ben, Glen and the UX team) is not interested.  Therefore there are no consumers for this request.

I don't think people enter bugs to "throw us off track" either, but that doesn't mean every request should be catered to.  We've had hundreds of people ask for moving tabs below the address bar, a number of people wonder where menu bars went, and the normal assortment of requests for formats like JPEG2000 and MNG.  None of these are requests we intend to fulfill regardless of the sincerity of intent behind them.

In the case of autoscroll we want to see spring-loaded autoscroll on drag and sticky autoscroll on click, like Firefox and IE.  The primary complaint we've heard from users is the lack of spring-loaded autoscroll on drag.  The secondary complaint we've heard is from people who do not like autoscroll.  That's a legitimate complaint, but it is one where we (the UX team) have decided that the downsides of adding an option to our options menu outweigh the gain of making some of the people who don't want autoscroll happy.

Please direct further feedback to me via email.