Initially hidden ComboBox do not load items since vaadin 25.2.0

[davidef]

Description

Initially hidden ComboBox do not load items since vaadin 25.2.0.
The same code is working fine as expected in 25.1.8

Expected outcome

ComboBox items are loaded when the ComboBox is displayed.

Minimal reproducible example

		ComboBox<String> addTokenComboBox = new ComboBox<>();
		addTokenComboBox.setVisible(false);
		addTokenComboBox.setItems(List.of("A","B","C"));
		
		Button addTokenButton = new Button("Add item", VaadinIcon.PLUS.create());

		addTokenButton.addClickListener(event -> {
			addTokenButton.setVisible(false);
			addTokenComboBox.setVisible(true);
			addTokenComboBox.setValue(null);
			addTokenComboBox.setOpened(true);
			addTokenComboBox.focus();
		});
		addTokenComboBox.addValueChangeListener(event -> {
			if (event.isFromClient() && event.getValue() != null) {
				Notification.show("Selected: "  + event.getValue());
				
				addTokenButton.setVisible(true);
				addTokenComboBox.setVisible(false);
			}
		});

		addTokenComboBox.getElement().addPropertyChangeListener("opened", event -> {
			if (event.getValue() != null) {
				if (event.getValue() instanceof Boolean value) {
					if (!value) {
						addTokenButton.setVisible(true);
						addTokenComboBox.setVisible(false);	
					}
				}
			}
		});
		
		add(addTokenComboBox, addTokenButton);

Steps to reproduce

1. Click on "Add Item"
2. The newly displayed ComboBox do not load the items

Environment

Vaadin version(s): 25.2.0

Browsers

No response

[web-padawan]

Warning

Automated reproduction — produced by the Claude Code repro skill. Needs human verification.
The steps, verdict, and root-cause pointer below were generated automatically and must be confirmed by a human before being treated as authoritative.

• Verdict: reproduced
• Hypothesis tested: The bug is an initially hidden lazy ComboBox never receives its item data, triggered by making it visible and opening it in the same server round-trip, observable as an open dropdown stuck on the loading spinner with empty (placeholder) items.
• Branch: repro/9622 — pushed to vaadin/flow-components
• Reproduced on: flow-components @ main (flow.version 25.3-SNAPSHOT, web components resolve to @vaadin/*@25.2.0 — the affected version)
• Present on main?: yes (still broken)
• Theme / Browser: Lumo / Chromium (Playwright)
• Screenshot:

Observed behavior

Clicking Add item makes the ComboBox visible, sets its value to null, and opens it. The dropdown opens but shows only a loading spinner — the items A, B, C never appear.

Inspecting the web component right after opening:

size: 3, opened: true, loading: true, filteredItems: [{}, {}, {}]

The server delivered the size (3 → 3 placeholder rows render), but the actual item data for the first page never arrives, so loading stays true forever and every row stays empty. Typing a filter (A) does not recover it either — the combo box stays loading: true with filteredItems: [], so no data page is ever delivered for this component.

Console is clean (only the dev-server favicon 404 and the Lit dev-mode warning).

Expected behavior

When the ComboBox is made visible and opened, its items (A, B, C) load and are shown in the dropdown. This worked in 25.1.x.

Steps to reproduce

1. Open http://localhost:8080/repro-9622.
2. Click Add item (the ComboBox starts hidden and is made visible + opened by the click listener).
3. The dropdown opens but is stuck on the loading spinner; the items never load.

Reproduction

How to run: from flow-components, start the IT server and open the route below.

CI=true mvn package jetty:run -Dvaadin.pnpm.enable -Dvaadin.frontend.hotdeploy=true -am -B -DskipTests \
  -pl vaadin-combo-box-flow-parent/vaadin-combo-box-flow-integration-tests

• Route / page: http://localhost:8080/repro-9622
• Scaffold: vaadin-combo-box-flow-parent/vaadin-combo-box-flow-integration-tests/src/main/java/com/vaadin/flow/component/combobox/test/Repro9622View.java

ComboBox<String> addTokenComboBox = new ComboBox<>();
addTokenComboBox.setVisible(false);
addTokenComboBox.setItems(List.of("A", "B", "C"));

Button addTokenButton = new Button("Add item");
addTokenButton.addClickListener(event -> {
    addTokenButton.setVisible(false);
    addTokenComboBox.setVisible(true);
    addTokenComboBox.setValue(null);
    addTokenComboBox.setOpened(true);
    addTokenComboBox.focus();
});

add(addTokenComboBox, addTokenButton);

(This is the reporter's minimal example verbatim; the value-change and opened property listeners from the issue are kept in the scaffold but are not needed to trigger the bug.)

Root cause (suspected)

The failure is that the client never receives the first page of item data after the ComboBox transitions from invisible to visible+opened in one round-trip — the server sends the size (placeholders render) but no item data, so the dropdown is stuck loading. The flow-components ComboBox data bridge (ComboBoxDataController, which drives Flow's DataCommunicator and the client connector) is the code that governs this delivery:

flow-components/vaadin-combo-box-flow-parent/vaadin-combo-box-flow/src/main/java/com/vaadin/flow/component/combobox/ComboBoxDataController.java

Lines 245 to 288 in 2812a96

	void reset() {
	lastFilter = null;
	if (dataCommunicator != null) {
	dataCommunicator.setViewportRange(0, 0);
	dataCommunicator.reset();
	}
	comboBox.runBeforeClientResponse(ui -> ui.getPage().executeJs(
	// If-statement is needed because on the first attach this
	// JavaScript is called before initializing the connector.
	"if($0.$connector) $0.$connector.reset();",
	comboBox.getElement()));
	}
	/**
	* Called to confirm that an update has been processed by the client-side
	* connector
	*
	* @param id
	* the update identifier
	*/
	void confirmUpdate(int id) {
	dataCommunicator.confirmUpdate(id);
	}
	/**
	* Called when the client-side connector requests data
	*/
	void setViewportRange(int start, int length, String filter) {
	// If the filter is null, which indicates that the combo box was closed
	// before, then reset the data communicator to force sending an update
	// to the client connector. This covers an edge-case when using an empty
	// lazy data provider and refreshing it before opening the combo box
	// again. In that case the data provider thinks that the client should
	// already be up-to-date from the refresh, as in both cases, refresh and
	// empty data provider, the effective requested size is zero, which
	// results in it not sending an update. However, the client needs to
	// receive an update in order to clear the loading state from opening
	// the combo box.
	if (lastFilter == null) {
	dataCommunicator.reset();
	}
	dataCommunicator.setViewportRange(start, length);
	filterSlot.accept(filter);
	}

This Java code is unchanged across the regression window (last touched 2026-03, well before 25.2.0), and only the bundled @vaadin/combo-box web component was bumped to 25.2.0. So the regression most likely sits in the 25.2.0 platform bump — either the combo-box web component (the 25.2.0 scroller/initialization refactor in vaadin-combo-box-scroller-mixin.js / data-provider flow) or Flow core's DataCommunicator handling of a component that was invisible during its initial flush and is not re-flushed when made visible. This needs a human to bisect between web-components 25.1.x → 25.2.0 and the Flow core version.

Notes

• No IT-module pom change was needed — vaadin-button-flow and vaadin-notification-flow are already dependencies of the ComboBox integration-tests module.
• Reproduced with the platform's released web components (@vaadin/*@25.2.0) on top of flow-components main; no maintenance-branch switch was required since the current line is past 25.2.0 and still broken.