(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.
ToT Mac does not use native widgets.
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.
It would be good to know why this doesn't happen on Mac. See also: bug 8150.
Comment on attachment 12250 [details] simple fix r=me
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.
Simply removing the called to invalidateClick() altogether gives us behavior identical to Firefox.
Should this patch be landed as-is, or do you intend to update it so that we match Firefox?
Created attachment 12565 [details] alternate fix, matches firefox I would prefer if we matched Firefox's behavior. It seems more correct to me.
Comment on attachment 12565 [details] alternate fix, matches firefox OK, sounds fine.
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.