Fix: Close datepicker on touchstart

[clemens]

It seems that when the event system was reworked, the bug closed in #223 got reintroduced. This PR fixes this.

[acrobat]

Can you add tests to avoid regressions like this in the future? Thanks!

[clemens]

I've never done this for JS so I hope it's OK like this: I just copied the test that's used for the corresponding mouse event to a separate directory and let it trigger a touchstart event instead of mousedown.

Let me know.

[acrobat]

Looks good to me! @vsn4ik @Azaret do you guys have any comments on this?

[vsn4ik]

LGTM!

[acrobat]

Thanks @clemens!

[acrobat]

Hmm I've just merged but this pr came to my attention #1284, are we also introducing the same bug again @clemens?

[clemens]

That's quite likely. However: Mousedown wasn't triggered for me despite not scrolling – hence the PR.

I'll double check and get back to you.

[acrobat]

That's great! Or if you have/find another workaround to support both cases would be nice!

[clemens]

I've done a little investigation and it looks like there's no easy way to get both things working properly. The best idea I have (inspired by things I think I remember from other libs) would be as follows:

• capture the origin of a touchstart event
• trigger the closing action on mouseup and touchend instead of mousedown and touchstart (the mouseup change is merely for consistency because it's the equivalent of touchend)
• cancel the touchend handling if the distance between the origin captured in touchstart and the destination in touchend is below a certain (user-editable) threshold (i.e. it counts as a click rather than a scroll below that threshold)

I'm afraid my JS skills probably don't suffice for a decent implementation of that solution.

For the time being, I'd argue that being able to close the datepicker by touching outside of it is more important than the datepicker staying open when the user scrolls – but maybe that's just my point of view. I'd understand if you want to revert my PR.

Cheers,

• C.