You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There appears to be an issue with selection when trying to select timeslots and moving upwards.
Its even happening in your own examples, so i've added that link to reproduce it easily, as well as video to display it. Just start adding timeslot and start moving upwards, it will change the start to 00:00
Note: I am also having this issue when i bundled it with rollup and used it in my UI-components lib, but when i install it directly in the app, it works fine, could be some issue with react-big-calendar and rollup?
Expected Behavior
When selecting timeslots upwards, it shouldnt move the start selection to 00:00
Actual Behavior
When used timeslot selection it moves the start slot all the way up to 00:00
Check that this is really a bug
Reproduction link
https://jquense.github.io/react-big-calendar/examples/index.html?path=/docs/examples--example-2
Bug description
Screen.Recording.2024-03-13.at.11.07.05.mov
Hey guys,
There appears to be an issue with selection when trying to select timeslots and moving upwards.
Its even happening in your own examples, so i've added that link to reproduce it easily, as well as video to display it. Just start adding timeslot and start moving upwards, it will change the start to 00:00
Note: I am also having this issue when i bundled it with rollup and used it in my UI-components lib, but when i install it directly in the app, it works fine, could be some issue with react-big-calendar and rollup?
Expected Behavior
When selecting timeslots upwards, it shouldnt move the start selection to 00:00
Actual Behavior
When used timeslot selection it moves the start slot all the way up to 00:00
react-big-calendar version
1.11.0
React version
18.2.0
Platform/Target and Browser Versions
Chrome 122.0.6261.94, Mozila 123.0.1, Safari 17.2.1
Validations
Would you like to open a PR for this bug?
The text was updated successfully, but these errors were encountered: