docs: clarify CdpHttpRequest owns its logger (upstream #15338 N/A)

[kblok]

Tracks puppeteer/puppeteer#15338 from puppeteer-core-v25.7.0.

Verdict

No behavioral change. Upstream fixed crashes where request error handlers did (this.frame() as any).logger after the frame was detached (frame() null).

PuppeteerSharp already avoids that pattern:

• CdpHttpRequest takes ILoggerFactory, stores _logger, and HandleError uses that instance
• NetworkManager passes the factory when constructing requests
• BiDi request error paths do not look up a logger via Frame

What changed

• Documented on CdpHttpRequest that the logger is request-owned so detach-safe error handling is intentional (upstream equivalent already present)

Test plan

• Full CI green (path-filtered build triggered by the .cs comment change)

  

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[kblok]

Upstream PR #15338 → PuppeteerSharp

Upstream

• PR: puppeteer/puppeteer#15338
• Title: fix: logger calling causing crashes
• Summary: Upstream crashed when request error handlers accessed (this.frame() as any).logger after the frame was detached (frame() null). Fix stores a logger on the request and passes it from NetworkManager / BidiFrame.

PuppeteerSharp mapping

Upstream	PuppeteerSharp
Request-owned logger	CdpHttpRequest already takes ILoggerFactory and stores _logger
NetworkManager passes logger	Already passes _loggerFactory when constructing requests
Avoid Frame.Logger in error paths	HandleError uses request _logger only

Changes

No behavioral change. Documented on CdpHttpRequest that the logger is intentionally request-owned so error handling stays safe after frame detach (upstream equivalent already present).

Verification

• Build (Chrome/CDP): success
• CdpHttpRequestTests: passed