Bug 254732
| Summary: | Make SelectorQueryCache global | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Antti Koivisto <koivisto> |
| Component: | DOM | Assignee: | Antti Koivisto <koivisto> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | esprehn, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=260556 | ||
Antti Koivisto
It is currently per-Document.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/107414722>
Antti Koivisto
Pull request: https://github.com/WebKit/WebKit/pull/12170
EWS
Committed 262362@main (bc149c287545): <https://commits.webkit.org/262362@main>
Reviewed commits have been landed. Closing PR #12170 and removing active labels.
Elliott Sprehn
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
The cache key contains the security origin, I don't think there is attack like that.
Elliott Sprehn
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!