[Bug][Calendar] Incorrect month selection from the left scrollbar

[kanoshin]

I'm submitting a...

• Bug report

Current behavior

Datepicker selects the wrong month after using the month navigation on the left. The bug described here still reproduces with certain screen resolutions and zoom levels.

This issue reproduces on my system with 33% zoom, but we have an overwhelming number of reports from different users with different zoom levels. We are also reproducing this with 67% zoom on wide screens, so the issue seems to be screen resolution and zoom-related. As a result, this became a CRITICAL problem for us.

Video recording

https://github.com/user-attachments/assets/29995cd0-5193-4d04-98f6-1c52e9441f08

Expected behavior

All zoom levels and screen resolutions work as expected.

Minimal reproduction of the problem with instructions

1. Open https://stackblitz.com/edit/react-sxy6p1-zlx8zu?file=index.js

2. Change Zoom to 33% in Chrome on Macbook Pro M1 2021

3. Select May 1st 2024

4. Select March 1st 2024

5. See that date becomes 06/01/2024

Browser:

• Chrome (desktop) version 127

[kanoshin]

@PekoPPT, is there an ETA for a fix that we can rely on? I noticed that you assigned Medium severity, but this is affecting more than 33% zoom for us.

[kanoshin]

@PekoPPT, it looks like I was able to fix this problem by patching the kendo code. In https://github.com/telerik/kendo-react/issues/1749 (v6.1.1 of @progress/kendo-react-dateinputs), this was semi-fixed by skipping scroll when it's coming from ScrollSyncService when the current scroll position is close enough (within MIN_SCROLL_STEP margin):

if (_this.restrictScroll && scrollProperty === 'scrollTop' &&
    (!Number.isInteger(current) || !Number.isInteger(value)) && Math.abs(current - value) < MIN_SCROLL_STEP) {
    return;
}

However, MIN_SCROLL_STEP is a hardcoded value and doesn't work for all screen resolutions and zoom levels. For example, with 33% zoom, ScrollSyncService has a discrepancy of ~12.

So another way to skip unnecessary scroll is to set _this.lastScrollToValue inside the scrollTo handler (i.e. last scroll position):

_this.scrollTo = function (value) {
    var scrollProperty = _this.direction === 'vertical' ? 'scrollTop' : 'scrollLeft';
    if (!_this.scrollContainer) {
        return;
    }
    var current = _this.scrollContainer[scrollProperty];
    if (_this.restrictScroll && scrollProperty === 'scrollTop' &&
        (!Number.isInteger(current) || !Number.isInteger(value)) && Math.abs(current - value) < MIN_SCROLL_STEP) {
        return;
    }
    _this.scrollContainer[scrollProperty] = value;
    _this.lastScrollToValue = _this.scrollContainer[scrollProperty];
};

And then, inside handleScroll avoid calling onScroll (which then calls scrollTo) by changing the following condition:

if (_this.props.onScroll && _this.containerScrollPosition !== _this.lastScrollToValue) {
    _this.props.onScroll.call(undefined, event);
}

That way, the call to scrollTo is completely avoided, and there is no need for a strange MIN_SCROLL_STEP logic.

High-level summary: Kendo listens to scroll events of the Calendar element. When clicking on a Month inside the Calendar, it creates two scroll events: one for the Month Picker on the left and another for the Date Picker on the right. Once the scroll event is received, it's being passed to the parent component (Calendar). It engages ScrollSyncService to make sure that the left and right parts are in sync. However, in the case of Month click, Month and Date pickers are already in sync since they were set programmatically. Hence, we can skip passing that event to the parent and engaging ScrollSyncService because the current scroll position equals the desired scroll position. If the scroll event is triggered by the user, the last position set programmatically is not going to be equal to the current position, and this will propagate the scroll event to the parent and engage ScrollSyncService.

[PekoPPT]

Hey, @kanoshin.

First of all, I am happy to hear that you've managed to patch the issue and secondly, BIG THANK YOU for sharing the solution you've used.

Your suggestion and detailed explanation will surely help our community members until we fix the issue in the official version of the DateInputs package.

We are currently in a planning period, in which there should be some internal improvements in all DateInputs, so we will also prioritize this bug. I cannot say exactly when the bug fix will be available, but it will be part of our planning for the next quarter I believe we will manage to provide the fix in the upcoming few weeks.

[iadnonov]

The proposed solution does not address all scenarios, and creating a comprehensive fix will take additional time to find a better approach. We need to consider edge cases and ensure that the solution is robust enough to handle various situations effectively. Out team will investigate further before proceeding with a final implementation.

[vveesseelliinnaa]

Reported again in Ticket ID: 1682254