Hi, @robertjanetzko.

Thank you, once again for contributing to our repository! As I mentioned to you in your PR, we will try to configure hammer.js in order to implement that functionality. During testing it on other touch devices it seems that we need to make sure scrolling is working consistently across them and that is why we will research and implement that in one of our future sprints. Tell me what you think.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

Hi @kdinev, I checked the issue and it is still reproducing.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

There has been no recent activity and this issue has been marked inactive.

This is also reproducible on a regular touchpad on a laptop.

After a little bit of research, I think we may need to redesign the way the time picker handles scrolling.

Right now we listen for scroll or pan events and based on the event.deltaY we calculate the next item in the scrolled list. Which is done by directly setting the value of the internal date object that corresponds to the appropriate minutes. hours, seconds, etc. The value that is being set is calculated by using the delta from the event. Later the same value is used in the template during *ngFor to regenerate the spinners. This means that the scroll that the time picker has is somewhat simulated with the *ngFor as it just re-renders the spinners every time the scroll or pan occur. The date object is also used in the input of the picker to synchronize its value with that of the spinners.

With the current approach we cannot really tamper with the delta returned by the events as any modifications would result in unwanted changes in the picker's date value. In turn, this would cause unwanted behavior such as scrolling past several hours at once or having to scroll multiple times in order to get to the next hour, etc.

What we need to do is decouple the picker's scroll strategy from its internal value. This way we will be able to safely modify the delta returned by the event to simulate slower or faster scrolling. The date object could still be modified in order to preserve synchronization between the spinners and the input but it should not be used for anything else.

Could an option be to enable the use of the native iOS and Android component input time to select the time? I think for many cases it is enough

@lalo-mx in our case the usage of the native <input type="time"> is not plausible since there are differences in the component's UI and behavior depending on the platform/browser. Our goal is for all of our components to be seamlessly integrated in any platform with a unified UI and this is why we generally don't rely on the native controls, but we build around them.

In the case of the time picker the input is of type=text since we have custom handling around parsing and populating dates in it through the usage of the IgxDateTimeEditorDirective.