[Webkit-unassigned] [Bug 24722] Sticky Autoscroll Fix

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24722





------- Comment #4 from jhoneycutt at apple.com  2009-03-23 16:22 PDT -------
(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.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.