Grid aria-rowindex is inconsistent when Grid is initially hidden

[HerbertsVaadin]

Description

When grid is visible from the start,
the table header row is marked with aria-rowindex="1"
the first row of the table body starts with aria-rowindex="2"

When grid is hidden, and then revealed,
the table header row is marked with aria-rowindex="1"
the first row of the table body starts with aria-rowindex="1"
there is no row with aria-rowindex="4" it skips directly to aria-rowindex="5"
if you have scroll, and scroll to the bottom, back to the top, the first row of the table body aria-rowindex="2", and the second row is also aria-rowindex="2"

Expected outcome

Table header row is marked with aria-rowindex="1"
First row of the table body starts with aria-rowindex="2"
It doesn't skip aria-rowindex="4"

Minimal reproducible example

import com.vaadin.flow.component.button.Button;
import com.vaadin.flow.component.dependency.Uses;
import com.vaadin.flow.component.grid.Grid;
import com.vaadin.flow.component.icon.Icon;
import com.vaadin.flow.component.orderedlayout.VerticalLayout;
import com.vaadin.flow.router.Menu;
import com.vaadin.flow.router.PageTitle;
import com.vaadin.flow.router.Route;
import jakarta.annotation.security.PermitAll;
import org.vaadin.lineawesome.LineAwesomeIconUrl;

import java.util.List;

@PageTitle("Two Grids")
@Route("two-grids")
@Menu(order = 4, icon = LineAwesomeIconUrl.TABLE_SOLID)
@PermitAll
@Uses(Icon.class)
public class TwoGrids extends VerticalLayout {

    private Grid<String> grid1;
    private Grid<String> grid2;

    public TwoGrids() {
        grid1 = createRegularGrid();
        grid2 = createRegularGrid();
        grid2.setVisible(false);

        var button = new Button("Toggle grid 2");
        button.addClickListener(event -> grid2.setVisible(!grid2.isVisible()));

        add(grid1, button, grid2);
    }


    private Grid<String> createRegularGrid() {
        var grid = new Grid<String>();
        grid.addColumn(String::toString)
                .setHeader("Regular");

        grid.setItems(exampleValues());

        return grid;
    }


    private List<String> exampleValues() {
        return List.of("One", "Two", "Three", "Four", "Five");
    }

}

Steps to reproduce

1. Create two identical grids.
2. Hide one of them initially.
3. After view has been loaded, reveal the grid that was hidden.
4. Verify in the revealed grids shadowdom its aria-rowindex situation.
5. Compare it with the grid that was initially visible to see the inconsistency.

Environment

Vaadin version(s): 24.7.3
OS: Linux Mint

Browsers

Firefox, Chrome

[vursen]

@claude Investigate this issue. It would be interesting to know if the bug is in the grid itself or in the virtualizer.

[claude]

Claude finished @vursen's task in 10m 20s —— View job

---

Investigation: Grid aria-rowindex inconsistent when Grid is initially hidden

• Read the issue and reproduce the reported behavior
• Locate where aria-rowindex is set (grid vs. virtualizer)
• Determine root cause
• Reproduce in a browser to confirm

Short answer

The bug is in the virtualizer, not in the grid. And it no longer reproduces on the current version — I could not reproduce any of the reported symptoms on this repo's current dependencies (@vaadin/grid / @vaadin/component-base 25.3.0-alpha4), so it looks like it was already fixed somewhere between 24.7.3 (the reported version) and now.

Why it's the virtualizer, not the grid

Body-row aria-rowindex is derived purely from row.index:

// vaadin-grid-a11y-mixin.js
__a11yUpdateRowRowindex(row) {
  row.setAttribute('aria-rowindex', row.index + this.__a11yGetHeaderRowCount(this._columnTree) + 1);
}

The grid never computes an index of its own — row.index is assigned entirely by the virtualizer:

// vaadin-grid-mixin.js
__updateVirtualizerElement(row, index) {
  ...
  row.index = index;      // index comes from the virtualizer's updateElement callback
  ...
  this.__updateRow(row);  // -> __a11yUpdateRowRowindex(row)
}

So the grid a11y code is a correct, mechanical derivation. The reported inconsistencies (first body row at 1 instead of 2, a skipped index, and duplicate indices after scrolling) all mean the virtualizer handed the grid wrong/stale row.index values.

The relevant mechanism sits in virtualizer-iron-list-adapter.js:

• While the scroll target has zero height, _render returns early (if (!this.isAttached || !this._isVisible) return;), and most handlers (flush, _scrollHandler, scrollToIndex) also early-return on offsetHeight === 0. So rows are set up / recycled while the size and offsets are not yet valid.
• __updateElement skips calling updateElement when el.__lastUpdatedIndex === index. If a physical element keeps a stale __lastUpdatedIndex from its hidden-state layout, its row.index (and therefore aria-rowindex) is not refreshed when the grid becomes visible and rows are reordered — which produces the duplicate/skipped values described in the issue.

The current adapter has explicit handling for this (e.g. the size setter forces this._assignModels() when !this._isVisible, and _assignModels does delete el.__lastUpdatedIndex for hidden elements), which is consistent with the bug being fixed on the client side.

How I verified

I built a Flow view matching the reproduction exactly (two grids with setHeader("Regular"), second one setVisible(false), revealed via a button) and inspected the shadow DOM with Playwright:

Scenario	Header	First body rows
Grid visible from start	aria-rowindex=1	idx0→2, idx1→3, idx2→4, … ✅
Grid hidden then revealed	aria-rowindex=1	idx0→2, idx1→3, idx2→4, … ✅
Revealed grid, scroll to bottom then back to top (200 rows)	1	idx0→2, … no duplicates, no skips ✅

In every case aria-rowindex === row.index + 2, exactly as expected. (Note: the existing vaadin-grid/toggle-visibility IT page does not reproduce it because its columns have no header text, so the header row count is legitimately 0 and body rows correctly start at aria-rowindex=1.)

Suggestion

Since it reproduces on 24.7.3 but not on 25.3, the fix likely already landed in web-components. Worth confirming against the exact 24.7 line the reporter uses and, if wanted, back-porting there. If it would help guard against regressions, I can add an integration test for the initially-hidden → revealed case (and the scroll round-trip) to this repo — just let me know.
• Branch: claude/issue-7448-20260713-1235

[vursen]

This issue got fixed as a side effect of vaadin/web-components#10443 in 25.0