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: ***@***.***>