Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: eb138906e241effe36255c50ed97b8b7343010fc
https://github.com/WebKit/WebKit/commit/eb138906e241effe36255c50ed97b8b7343010fc
Author: Brady Eidson <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
M Source/WebKit/Shared/Cocoa/CoreIPCNSURLRequest.mm
Log Message:
-----------
Excessive CoreIPCNSURLRequest logging from CoreMedia generated NSURLRequests
rdar://184133528
https://bugs.webkit.org/show_bug.cgi?id=321112
Reviewed by Ryan Reno.
In 315856@main we added what was meant to be restrictions on which properties
an application
could override in an NSURLRequest they pass in to the WebKit API. That patch
included logging
of "violations" to help diagnose breakage that might later occur.
The restrictions and logging were implemented in the CoreIPCNSURLRequest IPC
wrapper, with
the intention of catching app-supplied properties in the UIProcess before being
sending to
other processes. But this had the side effect of catching NSURLRequests created
from within
WebKit itself, such as the requests that come from CoreMedia for
<audio>/<video> playback.
There is a specific set of properties that ResourceRequest handles directly
that we explicitly
serialize out of the property set, but also passed into the "app provided
property" santizing
path. For those properties behavior was correct, but we errantly logged a fault.
There's cleanup that can be done here to make sure we only do the sanitization
on properties
that originate from the app inside the UIProcess instead of applying to all IPC
passes, but
for now we can just remove that errant logging.
All existing tests verify no behavior change, but "lack of logging" is not
explicitly testable.
* Source/WebKit/Shared/Cocoa/CoreIPCNSURLRequest.mm:
(WebKit::populateAppProperties):
Canonical link: https://commits.webkit.org/318658@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
