Sticky Autoscroll Fix

• Component: WebCore Misc.
• Status: RESOLVED WONTFIX

[Itai]

Middle-clicking on an area which is not a link causes WebKit to start scrolling and releasing the mouse button WebKit gets stuck in that mode. The main issue is that when middle-clicking on something which appears to be a link, it takes time to recover from the problem and loosing the position on the page is easy because any mouse movement at that point scrolls the page away from the content the user is interested in.

A number of bugs have been entered in Chromium for this:
http://code.google.com/p/chromium/issues/detail?id=5162
http://code.google.com/p/chromium/issues/detail?id=5759

[Itai]

Created attachment 28792 [details]
Fix for Sticky Autoscroll Problem

[Jon Honeycutt]

Comment on attachment 28792 [details]
Fix for Sticky Autoscroll Problem

Hi, Itai, thanks for the patch! Some comments:

> Index: WebCore/ChangeLog
> ===================================================================
> --- WebCore/ChangeLog	(revision 41862)
> +++ WebCore/ChangeLog	(working copy)
> @@ -1,3 +1,14 @@
> [phone]  Itai Danan  <set EMAIL_ADDRESS environment variable>

Your e-mail address is missing.

> +        Reviewed by NOBODY (OOPS!).
> +
> +	Prevent the problem of autoscroll being sticky, particularly for case when entering the mode is accidental.
> +	Codewise, a few lines were simply moved from on function to another a few lines below.
> +
> +        * page/EventHandler.cpp:
> +        (WebCore::EventHandler::handleMousePressEvent):
> +        (WebCore::EventHandler::handleMouseReleaseEvent):
> +

This comment isn't clear to me. It would be more clear to explain the change you're making exactly, e.g., "Stop auto-scrolling when the middle mouse button has been released."

I am r-ing, because this change doesn't match the auto-scroll behavior of other browsers, and I think matching other browsers is the best way to fix this.

With Firefox and IE, you have to mouse the mouse farther from the click point before the page begins scrolling, both browsers scroll more slowly than WebKit when the mouse is only a short distance from the click point, and neither browser will start an auto-scroll if the area clicked isn't scrollable (e.g., a page with no scrollbars). I think fixing these would resolve the issues that most people are having.

Bug #21794 is similar and is about supporting another mode of auto-scrolling, where the auto-scroll stops when the middle mouse button has been released.

[Itai]

Sorry if my explanation was not 100% clear. I assumed that 'sticky' was a universal UI term (it is on Windows, perhaps not on Mac). It means that anaction leaves the UI in a state which changes the behavior of subsequent events. A classic example is "Sticky Modifiers" which is used for accessibility use of the Shift/Ctrl/Alt keys. In this mode, you press and release a modifier (say SHIFT) and then press another key (say the letter 'e') and you get the equivalent of "SHIFT-e".

Now back to the problem at hand. I checked bug 21794 and unfortunately that does not solve the present usability problem because upon middle-click (and release - not drag) the autoscroll remains sticky.

To clarify, the issue comes from the use of middle-click on a link to mean "Open In New Tab" (as it does in every tab-supporting browser) and the relatively recent WebKit addition to use middle-click to initiate autoscroll (which can be user-disabled in every other browser, probably for this kind of usability issue). When there is something that appears to be a link (but is not) and the user middle-clicks on it, autoscroll takes over and the user has to take further actions to get out of that mode and then perform another action (like left-clicking on the area or middle-clicking somewhere else).

There are hundreds of reasons why someone would accidentally click on something that is not a link. A great example when UPS sends an email with package tracking information. Next to each package number there is a UPS logo with the words 'Click here to track'. Middle-clicking there just turns autoscroll on. Why? Because the email they sent does not contain a link but a Javascript onclick handler (which opens the tracking info in a new window or popup).

Now as for the desired behavior, here is why autoscroll should not be sticky. This even works in favor of those you actually use it:
- Accidental autoscroll triggering (middle-click on a non-link) returns to normal immediately. No action needed to get out of autoscroll.
- Entering autoscroll willingly, scrolling and return out to autoscroll mode requires 3 action: press, drag, release. In sticky mode it requires 5: press, release, drag, press, release.

Honestly when reading the description of this feature and bugs against it, it baffles me to see things like "press the scroll-wheel button" (on 95% of mice this is where the middle-click is) to start scrolling. I thought the scroll-wheel was for scrolling? Some prefer clicking and moving the entire mouse rather than wiggling a finger up and down. The latter is clearly less effort.

[Jon Honeycutt]

(In reply to comment #3)
> 
> To clarify, the issue comes from the use of middle-click on a link to mean
> "Open In New Tab" (as it does in every tab-supporting browser) and the
> relatively recent WebKit addition to use middle-click to initiate autoscroll
> (which can be user-disabled in every other browser, probably for this kind of
> usability issue). 

Maybe we should add a similar preference to WebKit.

> There are hundreds of reasons why someone would accidentally click on something
> that is not a link. A great example when UPS sends an email with package
> tracking information. Next to each package number there is a UPS logo with the
> words 'Click here to track'. Middle-clicking there just turns autoscroll on.
> Why? Because the email they sent does not contain a link but a Javascript
> onclick handler (which opens the tracking info in a new window or popup).
> 

This sounds like a bug. What do Firefox and IE do here?

> Now as for the desired behavior, here is why autoscroll should not be sticky.
> This even works in favor of those you actually use it:
> - Accidental autoscroll triggering (middle-click on a non-link) returns to
> normal immediately. No action needed to get out of autoscroll.
> - Entering autoscroll willingly, scrolling and return out to autoscroll mode
> requires 3 action: press, drag, release. In sticky mode it requires 5: press,
> release, drag, press, release.
> 

Personally, I agree, but the current behavior matches the platform convention. I think we should maintain that when resolving the issues that people are having.

[Itai]

(In reply to comment #4)
> (In reply to comment #3)
> > 
> > To clarify, the issue comes from the use of middle-click on a link to mean
> > "Open In New Tab" (as it does in every tab-supporting browser) and the
> > relatively recent WebKit addition to use middle-click to initiate autoscroll
> > (which can be user-disabled in every other browser, probably for this kind of
> > usability issue). 
> 
> Maybe we should add a similar preference to WebKit.

That is fine by me.

> > There are hundreds of reasons why someone would accidentally click on something
> > that is not a link. A great example when UPS sends an email with package
> > tracking information. Next to each package number there is a UPS logo with the
> > words 'Click here to track'. Middle-clicking there just turns autoscroll on.
> > Why? Because the email they sent does not contain a link but a Javascript
> > onclick handler (which opens the tracking info in a new window or popup).
> > 
> 
> This sounds like a bug. What do Firefox and IE do here?

Don't know about IE, but Firefox has the same bug.
 
> > Now as for the desired behavior, here is why autoscroll should not be sticky.
> > This even works in favor of those you actually use it:
> > - Accidental autoscroll triggering (middle-click on a non-link) returns to
> > normal immediately. No action needed to get out of autoscroll.
> > - Entering autoscroll willingly, scrolling and return out to autoscroll mode
> > requires 3 action: press, drag, release. In sticky mode it requires 5: press,
> > release, drag, press, release.
> 
> Personally, I agree, but the current behavior matches the platform convention.
> I think we should maintain that when resolving the issues that people are
> having.

Glad you agree. Now I also understand the need for uniformity across products in
the name of simplifying user experience but in this case I disagree because being
uniform creates A usability issue. Surely we are allowed to do better than other
browsers, not being different to be different, but to improve things further.

Given the implementation of the option as you suggested, this point would not be
as important. I think that would be the only sensible way to deal with this if
you also want to provide the just-like-Firefox behavior.

[Blake Sening]

Just to be clear, this issue should only be about "middle _press & hold_ & drag & release", where at the "drag" stage, the middle mouse button has *never* been released yet.  Then, at the "release" step, autoscroll stops.  This is the functionality already in IE and Firefox.

Otherwise, autoscroll should definitely be "sticky", ie. just _middle click_ (at which point the middle button is released after the click) and autoscroll stays on until the next middle click turns it off.

[Jon Honeycutt]

(In reply to comment #6)
> Just to be clear, this issue should only be about "middle _press & hold_ & drag
> & release", where at the "drag" stage, the middle mouse button has *never* been
> released yet.  Then, at the "release" step, autoscroll stops.  This is the
> functionality already in IE and Firefox.
> 

Bug #21794 tracks adding this functionality.

[Jon Honeycutt]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > 
> > > To clarify, the issue comes from the use of middle-click on a link to mean
> > > "Open In New Tab" (as it does in every tab-supporting browser) and the
> > > relatively recent WebKit addition to use middle-click to initiate autoscroll
> > > (which can be user-disabled in every other browser, probably for this kind of
> > > usability issue). 
> > 
> > Maybe we should add a similar preference to WebKit.
> 
> That is fine by me.

Bug #24791. I also filed bugs #24792, #24793, and #24794 for the other issues mentioned.

> Glad you agree. Now I also understand the need for uniformity across products
> in
> the name of simplifying user experience but in this case I disagree because
> being
> uniform creates A usability issue. Surely we are allowed to do better than
> other
> browsers, not being different to be different, but to improve things further.
> 

Sure, we can! However, I think its being the default behavior in IE and Firefox means that the vast majority of people expect this, even if some don't care for it. I think the best approach is to offer the user the option to disable it.

I am closing this now that we have another bug tracking the preference to disable the feature.