[Webkit-unassigned] [Bug 21794] Middle-click panning should be springloaded while dragging

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 1 07:22:43 PDT 2009


------- Comment #35 from idanan at chromium.org  2009-06-01 07:22 PDT -------
See inline:

(In reply to comment #28)
> I don't understand what Itai's patch does, or why it was r+ed and landed.

Not sure where the confusion comes from but clearly there is some, perhaps
because a number 
of bugs sound very similar. The title of this one is "Middle-click panning
should be springloaded
while dragging" which is implemented by this patch as a WebKit option.
Originally I had simply
fixed it in another webkit patch (24722) but that was rejected under the
grounds that some people
wanted this behavior as an option, although there was agreement (see comments
there) that the
springloaded behavior was desirable.

> It looks like it adds an option to toggle between "always do sticky autoscroll"
> (the old behavior) and "always do spring-loaded autoscroll".

> If this is in fact what it does, no client wants this.  Certainly what Chromium
> wants (and what I suspect Safari will want) is more what Loren's patch aimed
> for: spring-loaded autoscroll on drag, sticky otherwise.
That is wrong. See below.

> Can someone explain what benefit this patch has?  If not, I intend to revert it
> after a reasonable amount of time has passed.

The behavior for prior to this patch was problematic because when one
accidentally middle-clicks
on something the user inadvertently enters autoscroll mode and the page often
moves unpredicatbly.
This occurs a lot and is extremely annoying to some users. You can read the
long threads attached
to Chromium issues 5759 and 5162. For example, comment#9 is typical:

"I was so happy Chrome didn't have this feature for a long time (or at least it
worked on my PC I just didn't know about it) and then I updated to the latest
last week (around 5/23/09) and now I am ALWAYS accidentally middle clicking and
webpage FLYS  AROUND as I try to regain control again."

The code here gives an option that allows WebKit to expose either this behavior
or the one
described here which is a more efficient way of scrolling and does not exhibit
the problem
reported by our users:
- Spring loaded autoscroll means that users come of autoscroll automatically
upon mouse up.
So they don't lose the position on their page.
- In sticky mode, it takes 5 actions (down, up, drag, down, up) to move the
page and be
able to interact with it. In sringloaded mode, it takes 3 actions "down, drag,

Now, I do see that a number of very similar bugs (but not identical) were filed
in both
WebKit and Chromium which may have led to some confusion but clearly show that
users are
having issues here. WebKit now has the luxury of providing both types of
autoscroll and
also address the problem of accidentally entering autoscroll mode.

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.

More information about the webkit-unassigned mailing list