The dropDownList supports several keyboard shortcuts as documented in https://demos.telerik.com/kendo-ui/dropdownlist/keyboard-navigation. However, when e.g. a KeyDown event is triggered (and handled) by the widget, its propagation is not stopped. This behavior can be witnessed in this DOJO.

In our case, we e.g. use dropDownLists inside dialog windows that can be closed via ESC. When pressing ESC while a dropDownList is focused, this not only closes the dropDownList (as expected), but also closes the dialog.

The dropDownList should stop the propagation of events that it handled.

Bug report

When navigating between inputs and after using Shift+Tab for focusing on a previous input the DropdOwnList popup does not close on pressing 'Enter' key.

Reproduction of the problem

1. Open Dojo
2. Focus the text input
3. Press Tab to focus the DropDownList
4. Press shift-tab to focus the text input
5. Press again Tab to focus the DropDownList
6. Press Alt+down to expand the dropdown
7. Press the down arrow to select an option in the dropdown
8. Press Enter key

Current behavior

The popup does not close. If we directly focus the DropDownList and follow steps 6-8 the popup will close.

Expected/desired behavior

The DropDownList should close when pressing the 'Enter' key.

Environment

• Kendo UI version: 2022.3.1109
• Browser: [all]

Bug report

The value of a disabled DropDownList is not announced in the below screen reader -> browser combinations:

NVDA with Chrome
JAWS with Chrome

The value is correctly announced by NVDA in Firefox.

After testing the scenario with the ComboBox, the value was correctly announced in all screen reader -> browser combinations.

Reproduction of the problem

1. Open this Dojo example in Chrome with JAWS/NVDA - https://runner.telerik.io/fullscreen/ERAxiqIy/3
2. Click the Enable checkbox
3. Select a value from the DropDownList
4. Click the Enable checkbox again.
5. Focus the Checkbox and press the down arrow key.

Current behavior

The screen reader announces the disabled state of the DropDownList, but does not announce its value.

Note - the value of the regular select element below the DropDownList is announced.

Expected/desired behavior

The value of the disabled DropDownList should be announced in the above mentioned combinations.

Environment

• Kendo UI version: 2023.1.117
• Browser: [Chrome]

Bug report

`DropDownListSelectEvent.dataItem` is undefined when using keyboard to select the optionLabel, but is defined when using the mouse

Reproduction of the problem

Steps

Dojo: https://dojo.telerik.com/IvEXOvUH

Make a selection (e.g. "Apples").
Select the optionLabel item.

Expected

The value of DropDownListSelectEvent.dataItem is the same whether the selection is made via keyboard or mouse (assumedly).
The value of DropDownListSelectEvent.dataItem is clearly specified in the API docs when selecting the optionLabel.

Actual
The value of DropDownListSelectEvent.dataItem is "Select an option…" when selecting with the mouse.
The value of DropDownListSelectEvent.dataItem is undefined when selecting with the keyboard.

Environment
Kendo UI version: 2024.1.130
Browser: [all]

Bug report

When the style attribute is used to style the 'td' elements in the TreeList, the attribute is removed from the rendered markup.

Reproduction of the problem

1. Open the Dojo - https://dojo.telerik.com/@NeliK/ulIZuKEG and inspect the

Current behavior

The style attribute is removed.

Expected/desired behavior

The style attribute should persist in the rowTemplate.

Environment

• Kendo UI version: 2024.3.806
• Browser: [all ]

Bug Report

The cascade event is triggered on initialization of the DropDownLists

Reproduction of the issue

1. Open this Dojo - https://dojo.telerik.com/nGNFvRwt
2. Open the browser console

Current behaviour

The cascade event is triggered on initialization

Expected behaviour

The event should be triggered when the value of the "parent" DropDownList is changed.

Bug report

When the DropDownList is configured with autoWidth:true, each opening of the component increases the width of the popup with 1px

Reproduction of the problem

1. Open this Dojo example - https://dojo.telerik.com/VzPJHcmm
2. Open the DropDownList multiple times

Current behavior

The width of the popup increases with each opening

Expected Behavior

The width should remain the same

Environment

• Kendo UI version: 2025.1.227
• Browser: [all]

I am using the Kendo-UI Grid's resizeColumn method do change column widths programmatically (e.g., to distribute column widths by our own custom rules). I have noticed that doing so sometimes leads to unexpected results as demonstrated in this DOJO:

Assume a grid with two columns: one has a fixed size of 200px and the other has no explicit width set.

In the first example, we programmatically set the first column's width to 200px (which should not change anything since the column already is 200px wide. 

grid.resizeColumn(column, 200);

This works as expected.

In the second example, we programmatically set the first column's width first to 20px and then immediately to 200px. I would expect the final outcome to be the same, since the second column should compensate.

grid.resizeColumn(column, 20);
grid.resizeColumn(column, 200);

However, the second column does not shrink and the overall grid grows larger instead. Doing this repeatedly causes the columns to grow larger and larger over time.

Of course, this is a simplified example and I do not call resizeColumn() twice right after each other.

Bug report

Reproduction of the problem

Approach described in the documentation is not working as described after version 2024.4.1112

Dojo: https://dojo.telerik.com/pXPIOvsq/2 - works with version 2024.3.1015, broken in version 2024.4.1112

Current behavior

Splitter cannot be made resizable as documented.

Expected/desired behavior

It should be possible to change the resizable option for panes.

TicketID:

1713187

Environment

• Kendo/Telerik version: 2024.4.1112

Bug report

Reproduction of the problem

We noticed this issue on our client application. It is especially prominent on a slower network connection. We have a batch edit Grid (in cell editing). We clicked Add to create a new row, added data to it, double-clicked the Save Changes button, refreshed the page, and noticed we had 2 new entries instead of just 1 in the grid. We are currently using v2025.4.1111.

To make sure that it was not something isolated to our specific version / setup, I went to the Kendo grid demo site (https://demos.telerik.com/kendo-ui/grid/editing ) to try and reproduce. At the time of writing this ticket, the Kendo site used the latest version available, v2026.2.520.

Current behavior

The following steps reproduce the issue reliably.

1. Open the DevTools console
2. Click the Network tab and change the network throttle to be "Fast 4G"
3. Click Add in the Grid
4. Type in the cells
5. Click Save Changes several times rapidly
6. Observed multiple "Create" network calls in the DevTools Network tab
7. Refresh the page to see multiple "test567" entries in the Grid

TicketID: 1715189

Environment

• Kendo/Telerik version: Latest
• jQuery version: All
• Browser: [all]

The @progress/kendo-ui npm package creates the following dependency tree:

@progress/kendo-ui 2026.1.415
 |
  - @progress/kendo-pdfviewer-common ^0.6.4 -> 0.6.4
    |
     - pdfjs-dist 4.6.82 -> 4.6.82
       |
        - canvas ^2.11.2 -> 2.11.2
          |
           - @mapbox/node-pre-gyp ^1.0.0 -> 1.0.11
             |
              - tar ^6.1.11 -> 6.2.1

All packages have been updated to the latest version possible.

Versions <= 7.5.10 of tar have multiple known vulnerabilities:

• node-tar Vulnerable to Arbitrary File Creation/Overwrite via Hardlink Path Traversal - https://github.com/advisories/GHSA-34x7-hfp2-rc4v
• node-tar is Vulnerable to Arbitrary File Overwrite and Symlink Poisoning via Insufficient Path Sanitization - https://github.com/advisories/GHSA-8qq5-rm4j-mr97
• Arbitrary File Read/Write via Hardlink Target Escape Through Symlink Chain in node-tar Extraction - https://github.com/advisories/GHSA-83g3-92jg-28cx
• tar has Hardlink Path Traversal via Drive-Relative Linkpath - https://github.com/advisories/GHSA-qffp-2rhf-9h96
• node-tar Symlink Path Traversal via Drive-Relative Linkpath - https://github.com/advisories/GHSA-9ppj-qmqm-q256
• Race Condition in node-tar Path Reservations via Unicode Ligature Collisions on macOS APFS - https://github.com/advisories/GHSA-r6q2-hw4h-h46w

Bug report

Reordering in the same column is not working correctly

Reproduction of the problem

1. Open the Demos - https://demos.telerik.com/kendo-ui/taskboard/remote-data-binding
2. In the first column, move "Campaigns" below "Customer Research."
3. Check the Network tab of your browser, and no update is sent. The "Campaigns" is moved back to the top. Sometimes an update is sent but it contains the wrong index, so the item is still on top.

Current behavior

The task order remains the same

Expected/desired behavior

IT should be possible to reorder the tasks in the same column

The issue is a regression starting with 2025.2.520 version

Environment

• Kendo UI version: 2025.4.1111
• Browser: [all ]

I realize this has been covered by this workaround in the past, but the need to write extra code for moving the column back to the original position makes this seem a bit "hacky" and most importantly, the user experience of being allowed to drag the column in the first place just to see it jump back seems wrong.

The good news is that the kendoGrid already has a mechanism for preventing the columnReorder event from getting fired in the first place! The bad news is that it only happens for columns that have either of these 2 classes ["k-group-cell, "k-hierarchy-cell"]

My request is to have a configuration option that enforces that same behavior for specific columns as:

1. Add a "reorderable" flag to be set as part of the column configuration (set it to false for those we want to keep in place)

2. This flag will set a class on those columns the same way it works for columns with "k-group-cell" or "k-hierarchy-cell" classes, so the event can be prevented.

There is one important caveat to consider with this approach: Only columns at the front and the back of the grid can be locked in place, so there needs to be validation to prevent having non-reorderable columns among reorderable ones.