Events support

[itfranck]

There's some interesting stuff that I'd like to add regarding events.

All driver events

• element clicked
• Navigated
• ValueChanged

This could be used in other things alongside with a method that would start listening user action and build Selenium Powershell output based on events that occurred.

It kind of ties in with #84 but in some way better because you could do it all from the module.

I can see some additional uses from things like FindElementCompleted to allow the possibility to calculate the amount of time multiple elements appear on the page (To measure performance )

https://www.selenium.dev/selenium/docs/api/dotnet/html/N_OpenQA_Selenium_Support_Events.htm

[vexx32]

Events can be a bit weird in PS... you might want to throw event handling all in a background runspace so you can use Register-ObjectEvent for them without also being dependent on the main runspace being available to handle events.

Of course... I guess that can come with its own problems, I suppose. Hmm.

[itfranck]

Indeed.

I was not looking to register events when the module is loaded and manage them through the session.
Instead, I was thinking along the lines of something like

(These are "draft thoughts")

• Measure-SeLoadedElements (name pending)

When calling it, it would register the handlers and wait for specified elements to be loaded and return once the timeout expired or all the specified elements are loaded.
(Possibly with an asjob parameter?)

Use case
For instance, a webpage that lazy load a dozen components when ajax call.
You know some components shouldn't take more than x seconds to load and the slowest one should load under 10 seconds.

This potential cmdlet would wait for all components to be loaded and return (or start a job with -asJob. (To be evaluated)

--

As for the other driver events, I was also thinking about a cmdlet to "design tests" so you'd have events registered and start listening for user input / actions — eg: Start-SeInteractiveSession / Stop-SeInteractiveSession (name pending)

That cmdlet would be specifically more of a "design time" cmdlet rather than generic use case.

--

Therefore, events themselves would not be popping up everywhere at all time but rather be used in the bounds of specific cmdlets.

( That said, if I find out there's a direct / indirect event for when user close the browser, I might want to look into including something so I can manage removal from the internal list of browser if / when detected. )

[vexx32]

Yeah that would probably make a lot more sense. Looking forward to it!

[itfranck]

Keeping this in mind for later but I need to remove it from V4.0 milestone if I want to release at the planned date.