Multi-Windows

[Solido]

Hi!

Is there an some plan to support multi windows tests?

I would need to create and layout some and then launch some operations on different ones to validate a complex ui

Best wishes for 2026 patrol team

[fylyppo]

Hi! Thanks for the kind wishes - happy 2026 to you as well!

Could you please expand a bit on your use case? Are you referring to Desktop (native multi-window support), Web (multiple browser tabs/windows), or Mobile (split-screen/multitasking)?

Proposed API: Could you describe how you imagine writing a test for this?

It would be super helpful if you could provide a pseudo-code example of the API you are looking for.

[Solido]

Hey! Lets brainstorm this together. The best API would be a selector that branch to the conventional finder. My case is desktop but let’s try to find common ground with other platforms. Mobile is at the edge but web would give a solid feature for e2e testing. We may have multiple windows identifier but let’s start with titles that would redirect to a window controller and associated widget tree. Once there we can chain the common Patrol grammar for execution after asking for focus. $(#settingsWindowController).$(#namedTextfield) And final settingsWindow = $(#settingsWindowController) settingsWindow.nativeMethodCall() requirements before launching the TU like focus or resize close etc To avoid repetition surely a local context would help $window(settingsWindow) { $(#myTextField)… $(#otherFinder)… } This would simplify large existing tu migration to multi windows. Let me know what is feasible! Le mar. 6 janv. 2026 à 17:01, Filip Tuzimek ***@***.***> a écrit :

…

*fylyppo* left a comment (leancodepl/patrol#2871) <#2871 (comment)> Hi there! Thanks for the kind wishes — happy 2026 to you as well! 🚀 Could you please expand a bit on your use case? Are you referring to Desktop (native multi-window support), Web (multiple browser tabs/windows), or Mobile (split-screen/multitasking)? Proposed API: Could you describe how you imagine writing a test for this? It would be super helpful if you could provide a pseudo-code example of the API you are looking for. — Reply to this email directly, view it on GitHub <#2871 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ4MWIQLTZYRU2RQBZOBFD4FPL7JAVCNFSM6AAAAACQ2QOXESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJVGI3DSNZXGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[piotruela]

Hi, thanks for describing your case.
After a brief consideration, I think that with the current Patrol architecture, the simplest way to achieve what you need would be to design the test as follows:
Interactions within the first window/tab would be handled in the standard way (i.e. using WidgetTester and PlatformAutomator [$.]), while interactions with the second window/tab would be performed exclusively using PlatformAutomator, which operates above the application itself (where the currently running test also lives).
If we look at the web, enabling interactions with two or more browser tabs would most likely require extending the current API with new methods which might be considered as low effort. As for desktop platforms, they currently do not have support for native methods, and this is not on our roadmap at the moment.

[Solido]

Thanks for the feedback! Le mer. 7 janv. 2026 à 11:17, Piotr Maszota ***@***.***> a écrit :

…

*piotruela* left a comment (leancodepl/patrol#2871) <#2871 (comment)> Hi, thanks for describing your case. After a brief consideration, I think that with the current Patrol architecture, the simplest way to achieve what you need would be to design the test as follows: Interactions within the first window/tab would be handled in the standard way (i.e. using WidgetTester and PlatformAutomator [$.]), while interactions with the second window/tab would be performed exclusively using PlatformAutomator, which operates above the application itself (where the currently running test also lives). If we look at the web, enabling interactions with two or more browser tabs would most likely require extending the current API with new methods which might be considered as low effort. As for desktop platforms, they currently do not have support for native methods, and this is not on our roadmap at the moment. — Reply to this email directly, view it on GitHub <#2871 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ4MWJWHQ7DIUT22FVIVJ34FTMLLAVCNFSM6AAAAACQ2QOXESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJYGE4TGOJQHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[baslogic]

Following up on @piotruela's suggestion that extending the API for multiple browser tabs would be low effort — we've audited the current web platform to map out exactly what exists and what's needed.

Current web automator actions (21 total)

All operate on a single Playwright Page object per test:

Category	Actions
Interaction	tap, enterText, scrollTo (all with iframe support)
Keyboard	pressKey, pressKeyCombo
Navigation	goBack, goForward
Dialogs	acceptNextDialog, dismissNextDialog
Cookies	addCookie, getCookies, clearCookies
Permissions	grantPermissions, clearPermissions
Clipboard	getClipboard, setClipboard
Display	enableDarkMode, disableDarkMode, resizeWindow
Files	uploadFile, verifyFileDownloads

What's missing for multi-tab support

Method	Description	Playwright API
openNewTab(url)	Open a new tab	context.newPage() + page.goto()
closeTab(index)	Close a tab by index	context.pages()[index].close()
switchToTab(index)	Set the active tab	context.pages()[index]
getTabCount()	Number of open tabs	context.pages().length
getCurrentTabIndex()	Index of the active tab	Tracked internally
waitForPopup(action)	Capture a popup from window.open()	page.on('popup', ...)

What needs to change

There are three blockers in the current architecture:

1. Dart↔JS bridge is bound to one page — exposeBinding() in patrolPlatformHandler.ts is called once on the initial page. New tabs/popups don't get the binding, so Patrol actions can't target them.

2. Actions are hardwired to a single page — every action handler (tap, enterText, etc.) receives one page: Page parameter with no way to specify which tab to act on.

3. No page tracking — there's no registry mapping tab indices to Playwright Page objects.

Suggested approach

1. Add a PageManager on the TypeScript side that tracks all Page objects, listens for context.on('page') / page.on('popup') events, and calls exposeBinding() on each new page automatically.
2. Extend handlePatrolPlatformAction() to accept an optional tabIndex param, so all 21 existing actions can target any tab.
3. Add the new tab management methods to WebAutomator (Dart interface) and their corresponding TypeScript action handlers.

This keeps scope to web/browser tabs only — desktop multi-window is a separate concern as discussed above.

[baslogic]

Follow-up on the proposal above.

To clarify scope — when we say "web", this includes desktop browsers. Solido's original desktop use case is covered here since Patrol's web support runs on desktop browsers via Playwright. There's no separate "desktop multi-window" concern for this feature.

Also worth noting: tabs opened via openNewTab() or captured via waitForPopup() wouldn't be limited to the 21 existing Patrol web actions. Since Playwright is under the hood, the full Playwright API surface (page.locator(), page.fill(), page.click(), assertions, etc.) would be available on any tab. The tabIndex param on existing Patrol actions is a convenience layer, not a constraint.

Would appreciate any feedback on the proposed PageManager approach before we start a PR. @fylyppo @piotruela