Hi,

Not sure what the preferred way to report a problem is. I have posted it on GitHub as well:
https://github.com/telerik/kendo-react/issues/1519

Could someone help me out with this issue?

Thank you in advance.

Hello,

when using the StrictMode we get an UncaughtError when using the PopupComponent. Fe. when using the Date/Time-Picker.

ERROR
Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.
    at checkForNestedUpdates (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:27287:11)
    at scheduleUpdateOnFiber (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:25470:3)
    at Object.enqueueSetState (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:14067:7)
    at Component.setState (webpack-internal:///./node_modules/react/cjs/react.development.js:355:16)
    at PopupWithoutContext.componentDidUpdate (webpack-internal:///./node_modules/@progress/kendo-react-popup/dist/es/PopupWithoutContext.js:285:18)
    at commitLayoutEffectOnFiber (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:23328:30)
    at commitLayoutMountEffects_complete (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:24683:9)
    at commitLayoutEffects_begin (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:24669:7)
    at commitLayoutEffects_begin (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:24651:11)
    at commitLayoutEffects (webpack-internal:///./node_modules/react-dom/cjs/react-dom.development.js:24607:3)


The above error occurred in the <PopupComponent> component:
    at PopupWithoutContext (webpack-internal:///./node_modules/@progress/kendo-react-popup/dist/es/PopupWithoutContext.js:97:28)
    at eval (webpack-internal:///./node_modules/@progress/kendo-react-popup/dist/es/Popup.js:38:67)
    at div
    at AsyncFocusBlur (webpack-internal:///./node_modules/@progress/kendo-react-common/dist/es/hocs/AsyncFocusBlur.js:30:23)
    at TimePickerWithoutContext (webpack-internal:///./node_modules/@progress/kendo-react-dateinputs/dist/es/timepicker/TimePicker.js:87:28)
    at eval (webpack-internal:///./node_modules/@progress/kendo-react-common/dist/es/hocs/withPropsContext.js:28:95)
    at component
    at Field (webpack-internal:///./node_modules/@progress/kendo-react-form/dist/es/Field.js:37:22)
  ...

Hello,

Seems the link to the GridColumnMenu accessibility page from the DataGrid accessibility page is broken. 

Our tools are also warning us about empty links, caused by the GridColumnMenu button. How would we solve these?

Thank you,

Kristiyan Dimitrov

https://codesandbox.io/s/keen-panka-vctttd?file=/app/main.tsx

In the attached video I am showing the steps taken to reproduce the bug from the reproduction link. Basically if you change the year in DatePicker's calendar - no matter which year you select - the year gets reset back to 1911. I was not able to reproduce this in Kendo's CodeSandbox examples until I noticed that they were using the legacy ReactDOM.render() instead of the new React 18's createRoot. As soon as I replaced it I was able to reproduce the bug.

Another strange observation is that I am able to reproduce this bug in only half of my tries after refresh, another colleague reproduces it in 20-25% of his tries, so it doesn't happen all the time but eventually it will. That's why I've recorded a video on a fresh reload of the attached reproduction. Also, you can sometimes see the year is already wrong after selecting it, or after subsequently selecting the month, or sometimes you don't see the year is reset to 1911 until after you select the specific date and the popup closes.

Although there are other ways to reproduce this issue, the one shown in the video is the easiest to hit the bad scenario. Also, we were not able to reproduce the issue on the DateTimePicker, although it seems to use the same Calendar component underneath.

Our assumptions having previously reported similar problems in Kendo after migrating to React 18 is that due to the concurrent rendering / batching of state updates in React 18's createRoot - something breaks the virtual scroll used in the calendar (in the video when I point to 1912 being the next year after the selected 2021, if we scroll a bit, the virtual scroll picks up and updates the incorrect years) so we end up with stale data for the year when selecting the month/date. This means that there might be other unwanted side effects that we just haven't stumbled upon.

This is a severe bug for our application's end users as they are unable to change the year in the date picker reliably. Falling back to the deprecated ReactDOM.render is not an option.

The issue can be seen on your demo at https://www.telerik.com/kendo-react-ui/components/grid/

Steps: 

1) Load the demo from https://www.telerik.com/kendo-react-ui/components/grid/

2) Click on (x) in customerID grouping 

3) Look at the console and see the line with exception: 

The problem is that `e.originalEvent.target` is an svg object and it's className property is an object, not a string. The object is `SVGAnimatedString {baseVal: '', animVal: ''}` and it doesn't have the method indexOf.

Please fix asap.

Trying to drag an event in the scheduler duplicates (doubles) the event drag hints, but only in DayView. 

Reproduction:
https://codesandbox.io/p/sandbox/still-cloud-xrrx72?file=%2Fapp%2Fmain.tsx%3A21%2C26

Workaround:
The problem occurs when the event data doesn't have isAllDay property set. Even if you simply set it to false seems to resolve the issue. Problem is - Kendo's docs say that "The DataItem type does not limit the user to a specific fields in the data array", however the presence of this field is mandatory for the proper functioning of the DayView.

@progress/kendo-react-inputs@9.0.0

going back to this ticket, we'd like to use CTRL+up/down for our own purposes... as such, you can now disregard that feature request in lieu of fixing this bug =)

since this is undocumented behavior (documentation screenshot below) i believe we have a legitimate bug claim.

also, other controls like DateTimePicker reliably ignore the CTRL+up/down while implementing bare up/down as documented.

It would be ideal if toODataString could take an additional parameter that:

1. Takes a collection of expressions,
2. Each expression takes an Operator and Value,
3. Each expression returns a string or undefined, where the latter suggests we wish to suppress this expression.

Requesting for a load more button feature in tree view similar to the one in kendo Angular Tree View control

https://www.telerik.com/kendo-angular-ui/components/treeview/load-more-button

A json-file is needed to use localization in Kendo React. It's a lot of work to maintain these files when there are new versions. It's difficult to know which keys have been added, changed or removed.

When there are many items in the menu, the height should not exceed the page size. Now the scroll is not displayed.

https://stackblitz.com/edit/react-kxderjef

It refers to version 9.1.0, version 8.5.5 works fine

Thank you

When typing into a date picker and trying to type Feb 29th, 2024 (or any other leap year ofc) the date is updated incorrectly by the kendo date picker validation. As the user types the year their previous entry of 29 is updated to 28. This should update check should probably not occur until the user is done updating the input. If there is some fix or workaround we can do on our end to resolve this issue please let us know

Here's a video of the bug in our application

However, I was also able to reproduce the exact same behavior even in the documentation:

Hello! Is it possible to not show a room if there is no meeting on that day while simultaneously showing it on a different person because they have a meeting on that day? In the image below, I edited the data so Peter no longer had a meeting in room 2. Is it possible to get it to show Peter with just the meeting room(s) that they has data for, while keeping Alex with all the rooms that they have data for?

Peter -> Meeting Room 1 

Alex -> Meeting Room 1 AND Meeting Room 2

I think this would be a great feature to have. Lets say I have 100 students and/or 100 meeting rooms and all have a different days/times when they are needed. If there was a way to show ONLY what is being booked, or show ONLY what is free, that would be a fantastic feature for users and developers alike. 

https://stackblitz.com/edit/react-fuflvh-dwgfvu?file=app%2Fapp.tsx

Hello,

Please add a feature to highlight areas of a PDF on specific pages.  This feature is available in a different library - React PDF Viewer library - but that is apparently no longer supported, and has security vulnerabilities:

https://react-pdf-viewer.dev/examples/render-the-highlight-areas/

This is a critical feature for an application we are building.  Thank you for any assistance.

Hello,

After updating the kendo version in my project to "^5.1.0" I've noticed that some errors are appearing in our console when we are trying to resize items in the Scheduler. 

"use-resize-item.js:53 Unable to preventDefault inside passive event listener invocation."

I have attached a video with the error.

Thanks!

Hi,

We prefer to have keyboard up/down cursor correspond to navigating input focus up/down a row in the KendoReact Data Grid.

We are already successfully using custom GridColumn Cells to render inputs at all times in tandem with a Grid.onKeyDown handler that finds the next input to set focus.

(for anyone interested this only took a few lines of code to implement a dom navigation heuristic that finds the column index of the nearest TD via onKeyDown event.nativeEvent.target.closest("td") and then finds the corresponding td to that same column index in the next TR up or down, and then hits the first nested native html <input> found to call focus() -  this seems simple and durable to variances in nested components as long as there is a native input to be found, hence the need to render inputs at all times... which does run counter to the approach i saw represented in the KendoReact demos based on setting a particular dataitem's "inEdit" property which wasn't the look we were going for =)

The above cursor navigation is working but before it kicks in, inputs like the DateTimePicker are also taking a cursor up/down to change the date segment that currently has focus - and this doesn't seem to be optional behavior yet?

I believe the fundamental challenge to any dom "wrapper" approach is by the time an outer dom element receives onKeyDown it's too late for event.preventDefault or event.stopPropagation to hide it from the inner input element (the native kendoreact inputs in this case).

Hence the ask here to have an option to ignore that at on the individual KendoReact input components.

With previous KendoReact component builds (e.g. 8.2.0) we successfully proved "patch-package" various subcomponents of DateTimePicker, NumericTextBox and MultiSelect to prevent them from responding to up/down cursor events.

Of course patch-package approach is fragile to upgrades and sure enough recent need to take @progress/kendo-react-dateinputs@9.1.0-develop.6 to get into DateTimePicker formatPlaceholder bug fixes broke previous patches, highlighting need for more resilient fix.

I've attached the latest patch-package files to give precise reference to what keyboard events we're interested in disabling.

I'm assuming this is a feature request and happy to have it reallocated to a support ticket... but wanted to post it in open forums in case community might have alternative suggestions to achieve what we're looking for?

Maybe other approaches to what seems like it could be a general html nested component strategy pattern?

For instance, I'm hesitant to pursue any removeEventListener based approaches for fear of how that might conflict with how i vaguely understand react is continually recreating dom elements upon each render cycle, so i'd be open to encouragement in that direction if anyone has experience to share?

Also wondering if this falls into the realm of "accessibility" and maybe there's already ways to disable accessibility? (as negative as that sounds).

When your window control closes, focus returns to the element that invoked the window unless it is very unlikely users need to immediately reinvoke the window.

We use your window control as a popup search dialog. Our customers search for their data there, close the popup and then return to a dialog with lots of input fields.
The user had previously focused on one of these input fields and would like to have the focus back in this input field after closing the popup.
Which has worked wonderfully up to and including your version 8.0.0.

Unfortunately, this no longer works since version 8.1.0 and instead of the input field, only the button that previously opened the popup is focused. This change from the changelog seems to be responsible for this: "window: update focus management and kb navigation to match the ARIA spec".
It seems that your change uses a setTimeout internally, which keeps taking the focus away from our input field.

You can reproduce this behavior in a demo application. The first application is based on version 8.3.0 and you can reproduce the problem there by pressing the button and closing the opened popup. The focus that was previously in the input field is then on the button. Here: https://stackblitz.com/edit/react-xdpeqc-nycw86?file=app%2Fapp.tsx,package.json
In the second application based on version 8.0.0, you can see that the same process sets the focus directly back to the input field. Here: https://stackblitz.com/edit/react-xdpeqc-yab7m8?file=package.json,app%2Fapp.tsx

Nowhere in the ARIA specification here does it say that you should use a setTimeout to steal the user's focus again at a later time in order to set it on the button that opened the popup. On the contrary, point 2.1 describes exactly what we need:

You already had this feature in version 8.0.0 and could offer it again as a property with very little implementation effort. Please consider to add this old behaviour as a Window Prop again.