Bug 12133 – Form buttons don't receive click events if the mouse is dragged before releasing

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Dex Deacon]

(Windows only, probably because Mac uses native widgets)

1. Visit any page with a form submission button (such as google.com).
2. Press the left mouse button on the form button, but don't release.
3. Move the mouse a small amount, keeping the cursor within the button.
4. Release the button.

If the mouse moved at all before you release, the form button will not be clicked.

This happens because invalidateClick() is called in EventHandler::handleMouseMoveEvent(), which resets the click count and prevents further mouse-up events from dispatching a click.  I don't think simply removing that call is the right move, though.

[Dave Hyatt]

ToT Mac does not use native widgets.

[Dex Deacon]

Created attachment 12250 [details]
simple fix

The click should only be invalidated if the move starts a selection - otherwise, it makes more sense to allow mouse movements during clicks.

[Alexey Proskuryakov]

It would be good to know why this doesn't happen on Mac.

See also: bug 8150.

[Darin Adler]

Comment on attachment 12250 [details]
simple fix

r=me

[Dex Deacon]

Oops - this bug is a dupe of http://bugs.webkit.org/show_bug.cgi?id=8150 .

My "simple fix" patch fixes the first two cases in that bug's attached test case (http://bugs.webkit.org/attachment.cgi?id=7480).  The third case still results in no click if the mouse is moved.

If you test the third case in Firefox, you'll see that a click is registered if and only if nothing is selected as a result of a drag - as soon as text is selected, the click is invalidated.  In IE7, the click is never invalidated - as long as the mouseup is in the same element as the mousedown, it's a click.  Not sure which behavior we'd prefer.

[Dex Deacon]

Simply removing the called to invalidateClick() altogether gives us behavior identical to Firefox.

[Mark Rowe (bdash)]

Should this patch be landed as-is, or do you intend to update it so that we match Firefox?

[Dex Deacon]

Created attachment 12565 [details]
alternate fix, matches firefox

I would prefer if we matched Firefox's behavior.  It seems more correct to me.

[Darin Adler]

Comment on attachment 12565 [details]
alternate fix, matches firefox

OK, sounds fine.

[Darin Adler]

I'm being sloppy here, not following our usual process and landing this change without an automated test. Next time I really need to do "review-" on a patch that fixes a bug that does not include a regression test for the fix.

Committed revision 19158.