Theoretically, this is possible.

In lieu of aspects for cross cutting concerns, I'm not opposed to this.

What I want this for is to be able to set expectations for alert/prompt/confirm dialog before they happen. Ideally knowing if executed WebDriver command resulted in alert/prompt/confirm dialog opening without extra API call would be great as well.

Linking to https://github.com/php-fig/fig-standards/blob/master/proposed/event-manager.md

This is now PSR-14.

Interfaces require PHP 7.2+

• https://github.com/php-fig/event-dispatcher/tree/master/src

reference:
https://github.com/seleniumhq/selenium/blob/trunk/rb/lib/selenium/webdriver/support/abstract_event_listener.rb

Brainstorming:

• consumer calls ServiceFactory to register their event dispatcher (whatever implements PSR14)
• AbstractWebDriver::curl() would dispatch the before/after events to the registered event dispatcher
• listeners would not be able to modify the request/response, or interrupt flow (eg throwing exception)

As for the event object, at minimum:

• before, url
• after, url, status

Stumbling blocks:

• Whether or not to include post parameters (ie can be large for upload file)
• Whether or not to include the response value (ie can be large for page source, screenshot, and download file)
• Parsing the url will be messy to figure out which webdriver command will be/was executed.

So, I think we should be identifying the webdriver command before calling AbstractWebDriver::curl(). This is complicated by the commands that we declare via @method and use via __call().