Console and page events
Console output, dialogs, requests, responses, failed requests, popups. Listen to the signals exposed by the PHP client and assert on what matters.
- Console Fail the test on a console error
- Dialogs A confirm box no longer blocks the run
- Popups New windows arrive as objects, not accidents
Console
Fail the test on a console error
Collect console messages while the scenario runs and assert none of them are unexpected errors. Browser-side failures written to the console stop shipping unnoticed.
Page and browser events →$page->on('console', function ($message) use (&$errors) {
if ('error' === $message->type()) {
$errors[] = $message->text();
}
});
Dialogs
A confirm box no longer blocks the run
Alerts, confirms, prompts, and beforeunload are handled by a listener that accepts or dismisses. Unhandled, they are auto-dismissed rather than hanging the page.
Handle a dialog →
Popups
New windows arrive as objects, not accidents
A window opened by the page surfaces as a Page you can drive with the same locators and assertions as its opener.
Handle a popup window →
Next step
Move from the tour to working code.
Choose the explanation, recipe, or runnable example that matches what you need next.
Common questions
Before you wire it into a suite.
Should console errors fail tests?
For product smoke tests, usually yes. Collect console messages during the scenario and decide which types or sources should fail the run.
Do dialogs need special waits?
Register the dialog handler before the action that opens the dialog. The handler accepts, dismisses, or inspects the dialog when it appears.
How do popups fit into the model?
A popup is another Page object. Wait for it around the click that opens it, then drive it with the same locators and assertions.