Let Playwright wait until page is fully loaded

0
I’m writing Playwright tests for a Mendix application where each click triggers loading a new page, but the URL does not change (navigation happens client-side). The challenge: Playwright starts interacting with the next element too early. Even though unique elements on the new page are visible, Mendix is still running microflows in the background. This causes flakiness because the page isn’t truly ready yet. What I’ve tried so far: Waiting for unique elements to be visible Waiting for network requests to finish Wrapping code in retry blocks Using assertions after navigation None of these fully solve the issue because Mendix microflows finish later than the spinner disappears, and this is never a problem for a human user but breaks automation. Question:Has anyone found a reliable way to make Playwright wait until a Mendix page is fully ready (including microflows) before continuing? Ideally without hardcoded timeouts.
asked
2 answers
0

I think you tried most of the elegant options. 

 

Since your problem seems to be serverside and your application does not give so much as a beep to tell you when it is done, you may have to slide a bit more to the dark side.

 

A less elegant option that sometimes doe the trick for me is to write a loop that checks for the desired result.

So click a thing, wait 5 secs for the desired result, if not there, click again, rinse and repeat.

 

The things we have to do to make UI automation work with Mendix... :)

answered
0

I have used two ways to handle retries. Playwright’s built-in expect().toPass() assertion block works in some cases, and I’ve also implemented a custom retry function in JavaScript. Both approaches help to some extent, but they don’t fully solve the issue.

The core problem isn’t that the element on page X isn’t visible—Playwright sees it and can interact with it. The issue is that even after the element appears, Mendix is still running microflows in the background. So while Playwright is happily clicking through to the next state (let’s call it page X+1), the app sometimes resets back to page X or an earlier state, likely due to a microflow completing and triggering a UI update. 

I’m curious—have you found a way to reliably retry a block of code in cases where all the UI elements are visible and enabled, but there’s still some hidden process running that causes instability later in the test? I’m trying to avoid hardcoded waits, because those don’t guarantee that all microflows are done and usually the automation engineer ends up 'upping' the hard wait amounts whenever the tests are failing in for example a pipeline.

answered