Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#15510 closed defect (worksforme)

CheckBox/RadioButton do not respond properly to touch

Reported by: Colin Snover Owned by: bill
Priority: undecided Milestone: tbd
Component: Dijit - Form Version: 1.7.2
Keywords: Cc: ben hockey, bryanforbes
Blocked By: Blocking:

Description

In dijit/tests/form/test_CheckBox.html on trunk, touching a radio button or check box has a delay until the synthetic click event fires. These should respond to touch like the test_Button.html tests but are not for some reason. Not sure exactly what is going on, or when to get this in.

Change History (12)

comment:1 Changed 7 years ago by bill

Component: DijitDijit - Form
Owner: set to Douglas Hays

How much delay you are seeing? I tried dijit/tests/form/mobile.html yesterday and it was responsive to me.

IIRC when you click a CheckBox or RadioButton you are actually clicking a native checkbox/radiobutton (with an underlying image).

comment:2 Changed 7 years ago by Colin Snover

The normal amount when you are waiting for a synthetic click to happen. I tap, wait about 300ms, see the grey overlay appear that indicates a synthetic event fired, the box is checked. I guess this delay exists for native checkboxes too.

comment:3 Changed 7 years ago by Douglas Hays

Resolution: wontfix
Status: newclosed

I also see the delay, but since the same delay exists on native checkboxes, I don't think there's anything that needs to be fixed.

comment:4 Changed 7 years ago by ben hockey

Resolution: wontfix
Status: closedreopened

by listening to the touchend event, we can avoid the 300ms delay for the click event (see https://developers.google.com/mobile/articles/fast_buttons). the "ondijitclick" code already has some logic for adding listeners to touchend but it's not applied for input or button. for dijit/form/Button, a handler for "ondijitclick" is added to a span and so it listens for the faster touchend event on touch devices. CheckBox? adds a listener for a "click" event to an input and so it suffers from the delay.

if there was a way to use ondijitclick to listen to touchend for inputs then we could see the same snappy resonponsiveness for those widgets on touch devices as well. there's possibly other ways to go about this but i would think that updating the logic in "ondijitclick" might be the way to approach this.

comment:5 Changed 7 years ago by Douglas Hays

Owner: changed from Douglas Hays to bill
Status: reopenedassigned

Changing to dijitclick doesn't make it 'snappy' since there's still the underlying INPUT that is the gating factor. Button uses div/span elements to emulate a native BUTTON.

comment:6 in reply to:  5 Changed 7 years ago by ben hockey

Replying to doughays:

Changing to dijitclick doesn't make it 'snappy' since there's still the underlying INPUT that is the gating factor. Button uses div/span elements to emulate a native BUTTON.

yes - i mentioned that

the "ondijitclick" code already has some logic for adding listeners to touchend but it's not applied for input or button.

thanks for looking into this further

comment:7 Changed 7 years ago by bill

Resolution: worksforme
Status: assignedclosed

Guys, I personally don't like the sluggish behavior either, but it's by design from Apple, and I don't want to contradict their intended UI behavior.

The idea is that while a single click toggles a checkbox, or presses a button, a double click will zoom the screen, or unzoom it if it's already zoomed, without doing anything else (i.e. without changing the checkbox's state). The 300ms intentional delay is to differentiate between those two events.

You might wonder what happens if the page has a <meta> tag to disable scaling. Apple still has the delay, even in that case. I'm not sure if that's intentional or not, but I'm going to assume the former.

So, I would say that CheckBox is responding properly to touch events.

PS: See also #14918

Last edited 7 years ago by bill (previous) (diff)

comment:8 Changed 7 years ago by bill

In [28880]:

add native checkbox for comparison, refs #15510 !strict

comment:9 Changed 7 years ago by Colin Snover

Well I guess we should not provide checkboxes that can be styled since that contradicts their UI too. And we should probably revert Button too since touching a <button> element normally also has a delay. :)

On a more serious & less hyperbolic note, this is a big problem because it makes it impossible to create good mobile interfaces with Dijit. When writing a hybridised Web app, you don’t want to have to reimplement all of your UI controls for each platform, but that’s exactly what is happening here. Instead of it Just Working and feeling good on a touch platform, these controls are sluggish and do not match the feel that a native control (i.e. native app, not web page) would have.

Forcing developers to use an entirely separate set of widgets to get a good Web app experience is not the right approach and, I think, will drive people to other toolkits that have better solutions for hybrid desktop-mobile app controls. Does this make sense? Should we maybe discuss this more here or elsewhere?

comment:10 Changed 7 years ago by Colin Snover

P.S. The reason that there is a delay with normal checkboxes is the same as everywhere else—so that the browser does not emit a synthetic click event if the user double-taps. It is not “intended” UI behaviour, it’s a compromise to allow users to zoom into sections of a page without triggering a click. If you are creating an RIA you are normally disabling zoom, and this should respond to a tap instantly.

comment:11 Changed 7 years ago by Colin Snover

Cc: ben hockey bryanforbes added

comment:12 in reply to:  9 Changed 7 years ago by bill

we should probably revert Button too since touching a <button> element normally also has a delay.

Right, it should be consistent.

Should we maybe discuss this more here or elsewhere?

Sure, we can talk about it on the mailing list.

Note: See TracTickets for help on using tickets.