Don't assume that page events means the BrowserContext has a page

CDP currently assumes that if we get a page-related notification (like a
request interception, or page lifecycle event), then we must have a session
and page.

But, Target.detachFromTarget can remove the session from the BrowserContext
while still having the page run (I wonder if we should stop the page at this
point??). So, remove these assumptions and make sure we have a page/session
in the handling of page events.
This commit is contained in:
Karl Seguin
2025-09-05 15:07:30 +08:00
parent 2522e7fe9c
commit ac10d5b2a3
3 changed files with 33 additions and 45 deletions

View File

@@ -179,8 +179,10 @@ fn arePatternsSupported(patterns: []RequestPattern) bool {
}
pub fn requestIntercept(arena: Allocator, bc: anytype, intercept: *const Notification.RequestIntercept) !void {
// unreachable because we _have_ to have a page.
const session_id = bc.session_id orelse unreachable;
// detachTarget could be called, in which case, we still have a page doing
// things, but no session.
const session_id = bc.session_id orelse return;
const target_id = bc.target_id orelse unreachable;
// We keep it around to wait for modifications to the request.
@@ -380,8 +382,10 @@ fn failRequest(cmd: anytype) !void {
}
pub fn requestAuthRequired(arena: Allocator, bc: anytype, intercept: *const Notification.RequestAuthRequired) !void {
// unreachable because we _have_ to have a page.
const session_id = bc.session_id orelse unreachable;
// detachTarget could be called, in which case, we still have a page doing
// things, but no session.
const session_id = bc.session_id orelse return;
const target_id = bc.target_id orelse unreachable;
// We keep it around to wait for modifications to the request.