RESOLVED FIXED254732
Make SelectorQueryCache global 
https://bugs.webkit.org/show_bug.cgi?id=254732
Summary Make SelectorQueryCache global
Antti Koivisto
Reported 2023-03-30 04:31:30 PDT
It is currently per-Document.
Attachments
Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2023-03-30 04:44:32 PDT
<rdar://problem/107414722>
Antti Koivisto
Comment 2 2023-03-30 04:58:36 PDT
Pull request: https://github.com/WebKit/WebKit/pull/12170
EWS
Comment 3 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.
Elliott Sprehn
Comment 4 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)
Antti Koivisto
Comment 5 2024-01-10 08:10:44 PST
The cache key contains the security origin, I don't think there is attack like that.
Elliott Sprehn
Comment 6 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!
Note You need to log in before you can comment on or make changes to this bug.