I'm submitting a bug report

Current behavior

In a Native Grid that has a multicolumn header which is locked, when the Grid is scrolled horizontally, the upper(shared) part of the multicolumn header is moving based on the scrolling direction.

Expected behavior

When the multicolumn header is locked it should not move along with the horizontal scrolling inside the Grid

Minimal reproduction of the problem with instructions

1. Open this example
2. Scroll the Grid horizontally

If the Grid is initialized with no items, the first call to resetTableWidth as part of the initialization sets the width style on the k-grid-table to 0px.

If any items are added afterwards this style remains, even though the autogenerated columns have a greater width. This leads to the grid not being visible until its size is set manually.

Sample (Grid demo with column definitions removed and changed load the data after mount instead of after creation): https://codesandbox.io/s/late-hill-rkdhc5?file=/src/Grid.vue

Describe the bug
The column virtualization functionality doesn't work when the Grid is configured to work in RTL direction.

To Reproduce

1. Open this StackBlitz example
2. No data is visualized inside the Grid
3. If we remove the :dir="'rtl'" configuration the Grid data is correctly displayed

Expected behavior
The Grid's column virtualization should work with both LTR and RTL configurations.

The current implementation of the Native Vue Grid doesn't provide an option to control the visibility of the column menu in each component column. 

Providing a property that can control the visibility of the different column menus will be very useful in scenarios when we want to create a customized column menu that contains a component with a popup. With the current implementation of the component, if we for example add a DatePicker to the column menu, the opening of the DatePicker's calendar triggers the closing of the column menu. Having a prop that controls the visibility of the column menu we can easily handle the described scenario. 

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
https://codesandbox.io/p/sandbox/beautiful-tristan-5nvvfy?file=%2Fpackage.json
open the console and click the export button.

Expected behavior
No error in console

Describe the bug

When exporting the Kendo UI for Vue Native Grid data to a PDF file and the paper-size property is set to true, if there are locked columns inside the Grid, these columns are exported as empty columns.

• Workaround - a possible workaround is demonstrated in this StackBlitz example

To Reproduce

1. Open this StackBlitz example
2. Press the button above the Grid and save the exported file
3. Open the saved file and see how the locked columns have been exported

Expected behavior
All Grid columns should be correctly visualized in the exported PDF file, no matter if they are locked or unlocked.

Screenshots

Additional context
If we set the paper-size to a pre-defined value like 'A4', the issue is not replicable

Describe the bug

When defining a footer in a locked native Grid column, the footer of the column is moving when the content of the Grid is scrolled horizontally.

To Reproduce

1. Open this CodeSandbox example
2. Scroll the content of the Grid to the right

Expected behavior
The footer inside the ID column should not move when scrolling the Grid's content

Screenshots

Describe the bug
When activating the keyboard navigation inside the Native Grid and there are custom cells in this Grid, the navigation between the cells(in a specific scenario) is slow.

Scenario: In a Grid whose cells are all custom, focus a random cell in the first column. Then press and hold the right keyboard arrow. The focused cell starts moving to the right and then freezes until the last Grid column is reached.

Here is a video demonstrating the described scenario: https://user-images.githubusercontent.com/41293735/202707680-1964d01e-dbd3-4a35-93c4-1dbcfd45e887.mp4

• The issue is replicable on Chrome and Chromium-based browsers, on Windows 10.
• Testing the scenario on Firefox(Windows 10), the issue cannot be reproduced.

To Reproduce
Steps to reproduce the behavior:

1. Open this StackBlitz example on Windows and Chrome/Chromium-based browser
2. Focus a cell in the first column of the Grid
3. Press and hold the right keyboard arrow

Expected behavior
The movement of focus inside the Grid should be smooth and visible

Describe the bug
The value of the data-grid-row-index attribute of the different Native Grid rows is always -1, no matter the scenario in which the component is used.

To Reproduce

1. Open this StackBlitz example
2. Inspect a random Grid row and see its attributes

Expected behavior
The different rows inside the Grid should have different values for the data-grid-row-index attribute.

https://stackblitz.com/edit/mzrap6-afgvuk?file=src%2Fmain.vue

reorder the second column
result the innderHTML is NOT visible

Expected behavior
result the innderHTML is visible

workaround: use inner array instead of innerHTML - https://stackblitz.com/edit/mzrap6-y35krb?file=src%2Fmain.vue

I'm submitting a...

• Bug report

Current behavior

The "type" GridColumn prop is not available in the Typescript definitions available in the GridColumnProps.d.ts file.

Expected behavior

The type prop should be available also in the Typescript context as it is available in this Knowledge base article

The native Grid allows you to lock selected columns inside it. When we have locked columns, these are constantly visible inside the Grid, while the unlocked columns can be horizontally scrolled to see their content. 

The width of the area in which the unlocked columns can be scrolled depends on a combination of the following:

• The number of locked columns
• The width of the locked columns
• The width of the Grid

Having the above, there are some scenarios in which the area where the unlocked columns are displayed can be covered by locked columns or its size can become so small that the Grid data cannot be read.

Some examples of how the area that displays the unlocked column can become invisible or minified in size are:

• In a Grid with many columns, define many of them as locked
• In a Grid with resizable columns, resize one or a few of the columns in a way their sum width is bigger than the Grid's width
• A few Grid columns are locked but the Grid's width is too small

The current Feature request is about a property that defines the minimum width of the area in which the unlocked columns are scrolled. It could be a property like minUnlockedColumnsVisibleAreaWidth. Having this property defined, it should have a bigger priority over the defined column widths. This means that if there is not enough space to display the different locked columns with their pre-defined widths, the locked columns should be resized in a way the minimum visible area for the unlocked columns has enough width to display data. 

Describe the bug
Grid rowRender is triggered for every more than once in in-cell editing scenario vue 2

To Reproduce
https://codesandbox.io/s/confident-wind-50llik
1 Click on some cell
Current: RowRender is triggered for every row
Expected: RowRender is triggered only for the clicked row

Add active class to the column menu icon once something in it is different from default

Currently we recommend using custom class on the header(https://www.telerik.com/kendo-vue-ui/components/grid/columns/column-menu/#toc-styling-the-column-menu-icon), yet not visualising that the menu is populated seems like a UI misleading issue when using the component so we should add it by default

I'm submitting a...

• Bug report

Current behavior

When a named slot template is used in the Grid, the PDF export functionality will not export the cells that have an applied template.

In the linked below example, after exporting the Grid to PDF, the header cell of the "UnitPrice" column is empty.
If you remove the headerCell: 'headerTemplate' configuration and export the Grid to PDF, everything is exported correctly.

Expected behavior

All Grid cells should be exported to PDF no matter if they have a template applied to their definition.

Minimal reproduction of the problem with instructions

1. Open this project.
2. Click on the "Export vie PDF component" button
3. Check the exported file

I'm submitting a...

• Bug report

Current behavior

If a column has a value of 0 and there is no editor defined for this column, when editing Grids' data, the input in which 0 should be displayed is actually empty.

Expected behavior

When editing the Native Grid, the data displayed when a row is not in edit mode should be the same as when the same row is in edit mode.

Minimal reproduction of the problem with instructions

1. Open this StackBlitz example
2. Edit a row whose UnitPrice value is 0
3. See the empty input for the UnitPrice field, when the selected row is in the "edit" mode

There is an issue with white space that appears when you scroll a Grid with Groupable and Virtualization configurations switched on.
Reproduction:

1. Go to this article.
2. Scroll the Grid till the end of the scroller
3. See the white space.

Jumping issue:
When you scroll the linked above example there is a strange "jumping" of the rows.

Currently, the Native Grid implementation doesn't provide an option for the implementation of the scenario from the following screenshot. 

The thing that can be currently customized in the grouping toolbar of the Native Grid is only its text. 

Please provide an option by which we can define a custom template for the grouping toolbar.

Describe the bug
When using a slot template inside the Grid, the content of the template should always have only one DOM element on the root level. If there are multiple elements on the root level, only the first element will be rendered.

In scenarios when we add a comment inside the slot template as a first element, the Grid recognizes it as the first element in the template and nothing will be rendered.

To Reproduce

1. Open this StackBlitz example
2. See the Unit Price column

Expected behavior
The rendering of the slot template shouldn't depend on the number of root elements inside it. The template should be rendered in scenarios with both single and multiple elements in the root.

Screenshots

Describe the bug
In scenarios when we dynamically add data to the beginning of the Grid, the component re-renders elements whose re-rendering can be skipped.

To Reproduce

1. Open this StackBlitz example
2. Click on the "add row to beginning" button

Expected behavior
The onUpdated method should not be called when adding a new row to the beginning of the Grid. Instead, if you open the browser's console, the result is that "updating..." is logged three times.