Playwright で console 出力・未捕捉例外・レスポンス・失敗リクエストを監視したいとき、Page 単位で page.on(...) を登録すると、そのリスナーは Page インスタンス生成が完了してからしか効かない。一方 context.addInitScript() で注入したスクリプトは最初のページの document 生成中にも実行されるため、そのタイミングで起きた console 出力・例外・レスポンス・失敗リクエストは、newPage() 完了後に登録した Page 単位のリスナーでは取りこぼす。

誤解しやすい条件

「newPage() の直後に page.on を登録すれば十分」という直感は、後続のステップ数が多い・複数回ナビゲーションするシナリオでは実害が出にくいため見過ごされやすい。しかし最初のページで注入スクリプト自体が壊れている場合や、後続ナビゲーションが無い（観測機会が最初のページ1回きりの）シナリオでは、その唯一の発生機会を逃し、異常が実際にはあるのに「問題なし」と誤判定する。

対策

Playwright の BrowserContext は Page 相当のイベント（console、weberror、response、requestfailed 等）を context レベルでも発行する。これらを context.newPage() を呼ぶ前（addInitScript の登録と同じタイミング）で登録しておけば、最初のページの生成中に起きるイベントも取りこぼさない。context レベルの weberror イベントは、ページ未確定時は null になり得るページ参照とエラー本体を返すオブジェクトで受け取れ、Page 専用の pageerror イベントの代替になる。response/requestfailed も、リクエストやレスポンスが所属する frame 経由（frame は必ず所属ページを持つ）で発生元ページを辿れる。

検証

意図的に最初のページ生成中にのみ例外が起きる状況（例えば注入スクリプト自体のバグ）を作り、context レベル登録では検知でき、newPage() 後に page 単位でリスナー登録する実装ではその1回限りの例外を取りこぼすことを、両方の実装で比較して確認する。