Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 644fa28b6001b27f16668c525e3b4f5216ed6cc5
https://github.com/WebKit/WebKit/commit/644fa28b6001b27f16668c525e3b4f5216ed6cc5
Author: Qianlang Chen <[email protected]>
Date: 2026-09-01 (Tue, 01 Sep 2026)
Changed paths:
A LayoutTests/inspector/unit-tests/cookie-storage-object-expected.txt
A LayoutTests/inspector/unit-tests/cookie-storage-object.html
M Source/WebInspectorUI/UserInterface/Controllers/DOMStorageManager.js
M Source/WebInspectorUI/UserInterface/Models/CookieStorageObject.js
M Source/WebInspectorUI/UserInterface/Views/CookieStorageContentView.js
Log Message:
-----------
[Site Isolation] Web Inspector: Cross-origin cookies are missing in Storage
until reloading with inspector open
https://bugs.webkit.org/show_bug.cgi?id=322549
rdar://185268264
Reviewed by BJ Burg.
When the frontend attaches to an already-loaded page, the Storage tab
lists a cookie bucket for a cross-origin iframe's host but shows no
cookies in it. Reloading with the inspector open makes them appear.
Reading the cookies already works: Storage.getCookies on the UIProcess
target serves the authoritative NetworkProcess store, which does include
cookies belonging to out-of-process frames. The frontend then discarded
them. Instead of bucketing by cookie domain, the view re-filtered that
list against the URLs of the resources in its frame model, requiring
among other things that a resource's path start with the cookie's path.
At attach time the only resource the frame model has for an
out-of-process frame is the RemoteFrame stub from Page.getResourceTree,
whose URL is the bare security origin; its path is therefore "/", and
every cookie with a directory-scoped default path is rejected. A reload
replaces the stub with the real document URL, which is why reloading
looks like a fix.
Bucket by cookie domain alone on the Storage path. Re-filtering an
authoritative, process-independent cookie list against what one
WebContent process happens to have loaded reintroduces the in-process
assumption that adopting the Storage domain was meant to escape, and it
hides cookies that genuinely exist even without site isolation. The
legacy Page path keeps its resource matching so that non-site-isolation
sessions see exactly what they saw before. The visible difference is
that the cookie's path and Secure attributes no longer act as filters:
a cookie scoped to a path the page never loaded, or a Secure cookie on
a page loaded over http, is now listed under its host. The table has
Path and Secure columns precisely so that scope stays visible. Buckets
still come only from frame hosts, so this is not yet a complete view of
the store.
The rule lives on WI.CookieStorageObject alongside canGetCookies and
getCookies, and gathers the resources the legacy path needs itself, so
the view no longer touches the frame model and the rule is testable
without a view. For the same reason the sidebar now asks
WI.CookieStorageObject whether cookies can be read at all rather than
testing for Page.getCookies: its buckets should not disappear when the
page target stops serving cookie commands.
Fixing the stub is separate work that this patch does not do, and the
cookie panel should no longer depend on it either way. The frame model
bootstraps from a single Page.getResourceTree on the page target, which
runs in the main frame's process and cannot describe a frame hosted
elsewhere; the stub is the most that agent can report. The gap is that
ProxyingPageAgent on the UIProcess already assembles an aggregated tree
spanning every process of the page, with layout test coverage, and no
production code asks for it. Cookies were one consumer of the stub; the
Network tab is a more visible one, where the iframe's subresources are
missing and its main resource has an empty display name. Tracked in
webkit.org/b/322556.
Test: inspector/unit-tests/cookie-storage-object.html
An end-to-end "attach after load" test is not expressible in the layout
test harness, which calls testRunner.showWebInspector() once before the
load event and offers no supported detach and reattach, so the new test
covers the filtering rule directly in both directions. The reported
case was verified by hand in MiniBrowser.
* LayoutTests/inspector/unit-tests/cookie-storage-object-expected.txt: Added.
* LayoutTests/inspector/unit-tests/cookie-storage-object.html: Added.
* Source/WebInspectorUI/UserInterface/Controllers/DOMStorageManager.js:
(WI.DOMStorageManager.prototype._addCookieStorageIfNeeded):
* Source/WebInspectorUI/UserInterface/Models/CookieStorageObject.js:
(WI.CookieStorageObject.get canGetCookies):
(WI.CookieStorageObject.prototype.get canGetCookies):
(WI.CookieStorageObject.prototype.getCookies):
(WI.CookieStorageObject.prototype.filterCookiesForHost):
(WI.CookieStorageObject.prototype._resourcesForHost):
(WI.CookieStorageObject):
* Source/WebInspectorUI/UserInterface/Views/CookieStorageContentView.js:
(WI.CookieStorageContentView.prototype._reloadCookies):
(WI.CookieStorageContentView.prototype._getCookiesForHost): Deleted.
Canonical link: https://commits.webkit.org/320272@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
