Bug 92589 – Send NoPart as pressed to scrollbar when mouse is out of it.

• Component: UI Events
• Status: UNCONFIRMED

[Carlos]

Coming from: http://code.google.com/p/chromium/issues/detail?id=43170

What steps will reproduce the problem?
1. Left-click on the scrollbar
2. while holding the left button down, move to the web content
3. right-click (still holding the left button down) - a menu should appear
4. release both mouse buttons
5. move back to the scrollbar

What is the expected output? What do you see instead?

the scrollbar will behave, as if you'd still had the right button down.

I have reproduced the issue in: Chromium Linux, Chromium Mac & Safari Mac


Proposed patch sets NoPart as pressed in the scrollbar when we move the mouse out of it
*NOTE*: this still allows to keep the scrollbar pressed and move the mouse in any direction and the scrollbar will follow while holding the click. (because ScrollableArea::mouseExitedContentArea is called AFTER the mouse click is released)

With the patch: when the user issues another event, (is when ScrollableArea::mouseExitedContentArea actually gets called) the scrollbar selection is now clear to avoid weird stuff like in the mentioned bug/steps; and also this enforces the logic that while the cursor is out of the scrollbar we are not selecting any portions of it with the mouse.

I get no regressions introduced from this

[Carlos]

Created attachment 155158 [details]
Patch

[Eric Seidel (no email)]

I'm not really sure what this does?  Can we test this?

[Carlos]

@Eric:
With the mentioned steps in my first comment on the bug, the scrollbar can misbehave (move as if we were pressing it, even though we were not).

The cause was that when issuing another mouse click event outside the scrollbar while keeping the scrollbar pressed (like the mentioned steps to reproduce the bug), the selection on the scrollbar was not cleared.

The patch avoids this by clearing the pressed part of the scrollbar when ScrollableArea::mouseExitedScrollbar is called, avoiding the unexpected behavior mentioned.

[Carlos]

Additional info for prev response to eric:

It is based on the following logic:
If we are handling a new mouse event that is outside the scrollbar, then there is no way we are still pressing the scrollbar as the mouse is already outside.

[Alexey Proskuryakov]

> 1. Left-click on the scrollbar
> 2. while holding the left button down, move to the web content
> 3. right-click (still holding the left button down) - a menu should appear

I'm not sure about step three. Should the mouse really respond to the other click? I don't even have a device physically able to register another click while the button is down.

What happens in other applications?

> the scrollbar will behave, as if you'd still had the right button down.

This sounds wrong indeed.

[Carlos]

@Alexey:
If I use the touchpad of a macbook pro, then yes indeed it is not physically able to do so.
But when using an external mouse (in either mac or win) or a Dell computer touchpad (independent buttons for right and left click) then I can reproduce it.

On Internet Explorer there is no response to the other click
On Firefox the scrollbar press is cleared (like the submitted patch does)

[Anders Carlsson]

Comment on attachment 155158 [details]
Patch

Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.