Opened 7 years ago

Closed 4 years ago

#15998 closed defect (patchwelcome)

dojox.mobile.Slider - touch vs clickeevnt

Reported by: gerhard presser Owned by: Adrian Vasiliu
Priority: undecided Milestone: 1.13
Component: DojoX Mobile Version: 1.8.0
Keywords: Cc:
Blocked By: Blocking:

Description

the mobile-slider uses touchstart and mousedown-events to initialize value-changing. this are the right events for the 'handle' but I think not for the 'touchBox'. In fact it causes problems in one of my mobile apps. I have sliders nested in a scrollable-pane - if scrolling of the pane is initialized on a slider, the slider gets changed instead. I think the correkt event on the 'touchBox' would be an onclick-event!? prove me wrong. regards

Attachments (1)

ticket15998.patch (1.3 KB) - added by Sebastien Brunot 6 years ago.
!Slider value can be set by a click on the slider bar instead of on a touch / mouse down. (IBM CCLA)

Download all attachments as: .zip

Change History (21)

comment:1 Changed 7 years ago by bill

Yah, I agree, and brought this up a few years ago IIRC. On Native iOS, like the "Sounds" page of the "Settings" application, touching the bar of a slider doesn't do anything, so it doesn't interfere with scrolling the page; you need to touch the handle to change the slider value.

The two problems with the current design are that:

  • it's hard to scroll a page full of sliders
  • the user may change the slider value by accident when he's trying to scroll the page

The third (meta) problem is that the behavior is not what the user expects.

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

comment:2 Changed 6 years ago by Sebastien Brunot

I've added a patch with a proposal for a new parameter, offHandleValueSetting, that allows the user to choose between:

1) the current mode of setting the Slider value by touching the bar anywhere (current behavior, that is still the default one with the patch applied);

2) a new mode (the one you're asking for), that allows to set the value by clicking (instead of touching) the bar anywhere. To enable this mode, set the new parameter offHandleValueSetting to the value "onclick".

3) a new mode (the one bill describes on native iOS) that only allows to set the value by dragging the handle (and by using the keyboard on desktop browser). To enable this mode, set the new parameter offHandleValueSetting to the value "none".

The patch also includes a manual test that present the three modes in the context of a scrollable view.

comment:3 Changed 6 years ago by bill

My preference is just (3), to make dojox/mobile sliders always work like iOS' native sliders, where the only way to set the value is by dragging the handle. I don't see any good reason to contradict Apple's design.

If we do need to support mode (2), is there any reason to also support (1) and/or (3)? I think developers will be confused and burdened by having to understand what the offHandleValueSetting parameter does.

comment:4 Changed 6 years ago by Sebastien Brunot

Just having 3 is possible, for sure. The idea here was to keep 1 as this is the current mode just to avoid any regression in client applications, and I added 2 because it was the original request in this ticket.

Any other user complaints about the current mode of operation ?

comment:5 Changed 6 years ago by Sebastien Brunot

My personal opinion is the more options the better, as long as it is easy to understand and set the different options. So maybe a "offHandleValueSetting" option is not clear enough, and I (we) should think about another way to set this mode ?

comment:6 Changed 6 years ago by Sebastien Brunot

note that on Chrome desktop and IE 10 desktop, the value of a range HTML5 element can be set with a mousedown on the bar (as this is the case with the current version of the component).

So maybe we could have a parameter "valueSettingMode" that can be set to "desktop" (default) or "ios" (and maybe a third one to activate value change with onclick ?) to select the mode of operation. I need to check on all platforms to see the default mode of operation of ranges / sliders...

comment:7 Changed 6 years ago by bill

Well, "barValueSetting" would be clearer than "offHandleValueSetting" or the nebulous "valueSettingMode".

My question remains though: If we do need to support setting the value by clicking the bar, why not just do mode (2)? I don't see how it can be classified as a regression nor how it could break any applications. What value do the (1) and (3) options add? I don't think users notice the difference between touchstart and touchend to set the value.

Changed 6 years ago by Sebastien Brunot

Attachment: ticket15998.patch added

!Slider value can be set by a click on the slider bar instead of on a touch / mouse down. (IBM CCLA)

comment:8 Changed 6 years ago by Sebastien Brunot

Fair enough. Patch updated so that click events on the bar generate a value update, instead of touchstart / mousedown events generating the value update.

comment:9 Changed 6 years ago by Adrian Vasiliu

Milestone: tbd1.9.1
Owner: changed from Eric Durocher to Adrian Vasiliu
Status: newassigned

comment:10 Changed 6 years ago by Adrian Vasiliu

gpresser, please tell whether a fix in 1.9.x would be enough for you, or you absolutely need it in 1.8.x too.

comment:11 Changed 6 years ago by gerhard presser

1.9.* is ok for me - I patched it for 1.8.* allready

comment:12 Changed 6 years ago by Adrian Vasiliu

sbrunot, just to be on the safe side: did you test on WP8 and Win8 touch devices? I'm asking because Slider started to listen to touch.press since 70fe7d16daa1fa873cc398b47e785681c6311d05/dojox which was done for the MSPointer support, while your patch replaces touch.press by listening to click events directly, thus possibly defeating the change done for MSPointer support. I think it's worth checking it.

comment:13 Changed 6 years ago by Sebastien Brunot

Tested in IE10 on Windows 7, it works.

comment:14 Changed 6 years ago by Adrian Vasiliu

Well, good, but this doesn't cover the case of touch devices right?

comment:15 Changed 6 years ago by Sebastien Brunot

No. Unfortunately, I don't have a Windows 8 touch device available now, so it will have to wait for next week or for someone else with immediate access to such device to kindly test the patch on it.

comment:16 Changed 6 years ago by Adrian Vasiliu

Okay. Well, I gave it a quick try on Nokia Lumia 920 WP8, and unfortunately my fears seem to be confirmed... You can double-check and investigate next week, but in my testing using tests/test_Slider.html, applying the patch makes the test show errors (the page displays an error counter), and the touch interaction with the knob is partially broken.

Last edited 6 years ago by Adrian Vasiliu (previous) (diff)

comment:17 Changed 6 years ago by Sebastien Brunot

I reproduced the issue on the Nokia Lumia 920 WP8. It appears that the problem is related to https://bugs.dojotoolkit.org/ticket/17228: the synthetic click event that is received does not includes the click coordinates, so an incorrect value (NaN) is calculated for the Slider value on a click. I'm affraid this might also be the case on some other touch devices, for the same reason.

Moreover, I noticed that event when fixing this issue, the resulting behavior on the Nokia Lumia is not really usable: as the slider handle is very small, it is really difficult to drag it to set values. As a consequence, I think we should test the slider design with each theme to make sure we solve the handler usability issues before applying a fix for the problem described in this ticket.

comment:18 Changed 6 years ago by Sebastien Brunot

Considering the timeframe, I think the resolution of this ticket should be postponed to version 1.10.

comment:19 Changed 6 years ago by Adrian Vasiliu

Milestone: 1.9.1future

comment:20 Changed 4 years ago by dylan

Milestone: future1.12
Resolution: patchwelcome
Status: assignedclosed

Given that no one has shown interest in creating a patch in the past 3+ years, I'm closing this as patchwelcome.

Note: See TracTickets for help on using tickets.