Bug 254732 - Make SelectorQueryCache global
Summary: Make SelectorQueryCache global
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Antti Koivisto
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-03-30 04:31 PDT by Antti Koivisto
Modified: 2024-01-10 08:21 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antti Koivisto 2023-03-30 04:31:30 PDT
It is currently per-Document.
Comment 1 Radar WebKit Bug Importer 2023-03-30 04:44:32 PDT
<rdar://problem/107414722>
Comment 2 Antti Koivisto 2023-03-30 04:58:36 PDT
Pull request: https://github.com/WebKit/WebKit/pull/12170
Comment 3 EWS 2023-03-30 13:25:58 PDT
Committed 262362@main (bc149c287545): <https://commits.webkit.org/262362@main>

Reviewed commits have been landed. Closing PR #12170 and removing active labels.
Comment 4 Elliott Sprehn 2024-01-09 13:08:42 PST
I think this introduces a performance cliff where documents with distinct selectors (ex with ids in them) fight over the cache. It also means there's a timing attack when process isolation is not enabled. You can call querySelector to see if a different origin has parsed a selector, which may also contain user identifiable information (ex. in attribute, id or class names)
Comment 5 Antti Koivisto 2024-01-10 08:10:44 PST
The cache key contains the security origin, I don't think there is attack like that.
Comment 6 Elliott Sprehn 2024-01-10 08:21:50 PST
Ah you're right, I missed that line:

Key { selectors, context, document.securityOrigin().data() };

that still means the cache is technically smaller in a process with many tabs or iframes, but I don't have data that shows that's an issue. Thanks for explaining!