Skip to content

feat: delegate waitForVaadin readiness checks to Flow#2160

Draft
Artur- wants to merge 2 commits into
mainfrom
wait-for-vaadin-in-flow
Draft

feat: delegate waitForVaadin readiness checks to Flow#2160
Artur- wants to merge 2 commits into
mainfrom
wait-for-vaadin-in-flow

Conversation

@Artur-
Copy link
Copy Markdown
Member

@Artur- Artur- commented Mar 3, 2026

Replace the synchronous polling script that checked document.readyState,
devServerIsNotLoaded, and active clients directly with a call to
Flow's whenReady callback, which now owns all readiness logic.

TestBench polls Java-side until whenReady is a function (handling dev
server startup where the page may not have Flow loaded yet), then
makes a single executeAsyncScript call to let Flow report readiness.

Remove the waitForVaadinLoopHook testing mechanism and update
integration tests to use whenReady=false and setTimeout instead.

@Artur- Artur- force-pushed the wait-for-vaadin-in-flow branch 2 times, most recently from 2c0976c to 6cfbe71 Compare March 3, 2026 16:09
@Artur- Artur- changed the title feat: replace waitForVaadin polling loop with single async call feat: delegate waitForVaadin readiness checks to Flow Mar 3, 2026
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 3, 2026

Test Results

246 tests   242 ✅  14m 30s ⏱️
 30 suites    2 💤
 30 files      1 ❌  1 🔥

For more details on these failures and errors, see this check.

Results for commit e389e12.

♻️ This comment has been updated with latest results.

Comment on lines +64 to +65
getCommandExecutor()
.executeScript("window.Vaadin.Flow.whenReady = false;");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this setting the test always fails because waitForVaadin almost immediately returns, since there's nothing waiting for the timeout expected by assertExecutionBlocked

@Artur- Artur- force-pushed the wait-for-vaadin-in-flow branch from b8748ef to 17f911b Compare May 2, 2026 05:52
Artur- added 2 commits May 2, 2026 08:55
TestBench used to reimplement Flow's "am I idle?" logic in an inline
JS poll loop that checked document.readyState, devServerIsNotLoaded,
and iterated Flow.clients for isActive(). Flow now exposes that as a
canonical Promise API (window.Vaadin.Flow.ready), so use it instead
and let Flow own the readiness model. Keeps TestBench in sync as
Flow's bootstrap evolves and removes a parallel implementation that
could drift.

waitForVaadin runs in two phases: a short Java-side poll for the
ready function to be defined (survives dev server page reloads),
then a single executeAsyncScript that calls Flow.ready({ timeout })
with the remaining budget. Both fulfilment and rejection resolve to
the same callback so a JS-side timeout still releases the script.

The waitForVaadinLoopHook reflection seam is gone; integration tests
now drive readiness from JS (setTimeout flipping Flow.ready) and use
Flow.ready = false as the not-ready sentinel, matching the dev-mode
loading page. Drops waitForVaadin_noFlow_returnsImmediately since
Flow is now required to be loaded.
@Artur- Artur- force-pushed the wait-for-vaadin-in-flow branch from 17f911b to e389e12 Compare May 2, 2026 05:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants