PDA

View Full Version : [CLOSED] Button fail to be clicked - if user drags mouse pointer slightly while mouse is down



Drömbolaget
7 Nov 2013, 1:59 AM
Major bug with click handling in Button. The click event is not fired if you move the cursor while the mouse button is down and move it in/out of text/icon element - but still release the button while inside the button.

Versions
Chrome "30.0.1599.101 m"
Firefox 24.0
Windows 7 SP1

Steps to reproduce
Use Google Chrome or Mozilla Firefox
Go to http://try.sencha.com/extjs/4.2.0/docs/Ext.button.Button.1/
(http://try.sencha.com/extjs/4.2.0/docs/Ext.button.Button.1/)
Inspect the button, locate the <div><a><span> that the button is composed of.
Press mouse button down on <div> or <a> of Button.
Move cursor so that it is on text <span>.
Release mouse button
Expected result
Handler activated, alert dialog opened with the text "You clicked the button!"

Actual result
Nothing happens at all for Google Chrome and Mozilla Firefox.
Internet Explorer opens the alert every time.

Variations of the bug
If you start by pressing mouse button down on a text span and release on button <div> or <a> the same problem appears.

Severity?
Id' say about one in three times while clicking buttons the click handler fails to fire, I don't know if I move the cursor while clicking more than other users. But it shouldn't be this way. This problem introduces the notion to the user that buttons must be double or even triple clicked and they will start doing so unnecessarily on all buttons.

The problem is most prominent on small buttons, such as icon buttons, since the amount of padding vs content is more equal.

evant
7 Nov 2013, 4:10 AM
It's fairly difficult to say this is a bug. The button has always behaved this way, we listen to the click event on the underlying button element. The same thing happens if you click on a link and move your mouse a bit.

You can configure the 'clickEvent' option to be mousedown if it's presenting a problem for your users, but, but I don't see any reason to change this now.

Drömbolaget
7 Nov 2013, 5:51 AM
I still argue that this behavior is a bug.


The reason for dismissing this as "not a bug" through "the button has always behaved this way" is rubbish. Bugs are bugs even if they're old.


This reason "The same thing happens if you click on a link and move your mouse a bit." is also rubbish, you can move the mouse while mousedown and release a bit away while still on the link and the browser will still navigate to the link. Sure if you release the mouse button while outside the link nothing will happen. That is the intended behavior. But this problem is mousedown and mouseup inside the same button.


This problem is specific for ExtJS. It doesn't happen on native HTML buttons! It never happens on native Windows/OSX/Android/iOS apps either.


It never happens in Internet Explorer either, but does in Firefox and Chrome. I argue that ExtJS should abstract away any differences between platforms.


I believe this bug exists only because the event handler doesn't account for the button to consist of multiple elements (a and span inside div) and doesn't take care of handling the edge case where mouseup and mousedown occurs on different elements within the same Button.


So if I use native <button> elements that the ExtJS Button tries to emulate/improve this problem never happens.


This is not the behavior I as a user expect of a button. "Sometimes I need to double or triple-click buttons, but not always". >:)


--


Going the route of using mousedown event is not a solution - that removes the option for the user to decide when the click event should occur (thorugh mouse up normally) and it also removes the option for the user to cancel the click through moving the cursor outside the button and doing mousup there. Not an acceptable solution.


The Button just fails to emulate HTML <button> and native application buttons.


By the way the same problem occurs for Buttons with icons.

Gary Schlosberg
7 Nov 2013, 9:30 AM
I'm not able to recreate this. It seems to make no difference for me whether clicking in the background and moving to text pixel or vice-verse -- the alert always fires in Firefox 24 or Chrome 30. The only time it doesn't fire is if I move the cursor off of the button before releasing, but as you say that is the default behavior of an HTML button/link. In which operating system are you seeing this issue?

Drömbolaget
7 Nov 2013, 11:56 PM
I'm seeing this both in the example page I linked to (ExtJS 4.2.0) and in our app using 4.1.3. I'm on Windows 7 SP1, using Chrome "Version 30.0.1599.101 m" and Firefox 24.0.

My colleague is also on Windows 7, same version of Chrome, same behavior.

In our app, the Button actually renders a <button> element as well (the example link doesn't), but the same problem is experienced there.

I have recorded a video of the problem. It's rather high so you might need to scroll the page down a bit to see relevant part of Chrome's debugger.

You notice the mousedown by the "pressed" class being added to the Button outer element, and the mosueup with pressed being removed.

I hover the <spans> so you see where they are located the first few seconds.

http://screencast.com/t/RryZDn8vBa

If you mousedown on a span and mouseup on the parent <a> or <div> the click won't fire. The same goes for mousedown on <div> or <a> and mouseup on <span>.

Likely you just don't account for the mousedown and mouseup occuring on different html elements that the Button is composed of?

Drömbolaget
2 Dec 2013, 1:11 AM
I guess you didn't watch the video?

Drömbolaget
20 Jan 2014, 12:56 PM
The problem remains in ExtJS 4.2.2 on Windows 8.1 with Chrome 32.0.1700.76 m.
IE11 on Windows 8.1 works correctly.
Nothing has changed, the bug is still there.

Same problem in official docs live demo, the padding is smaller here, but the issue is the same.
http://docs.sencha.com/extjs/4.2.2/#!/api/Ext.button.Button
(http://docs.sencha.com/extjs/4.2.2/#!/api/Ext.button.ButtonDon't)
I don't understand why you closed this bug report. The problem is simple and reproducible on every machine I've tested it on.

mwilliamsShields
15 Sep 2014, 11:00 AM
I believe that this bug should be reopened. I am also experiencing the same issue.