-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative: make :visited main-frame only #1
Comments
Chat widgets are sometimes a cross-site iframe with links. Seems in its current state sandboxed pages and embeds would get there visited status removed after a reload. |
I think removing state from sandboxed frames is more of a feature than a bug -- documents from opaque origins aren't supposed to maintain state (e.g. no cookies, Re: limiting :visited to the main frame, I see how it could let us avoid some complexity. However, it would also reduce some of the utility of visitedness, e.g. in scenarios with same-origin iframes; I'm a little worried that it might limit functionality in a way we could avoid if we went with a triple-keyed design (but AFAIK we don't have any data to either support or disprove this). Another benefit of triple-keying is that it aligns the partitioning design with what we've done for HTTP cache and network state, so there's some conceptual consistency in how we're separating various kinds of client-side state. |
Yeah feature just wanted to ensure that frame origin stayed included. It seems unlikely visited links can just be disabled for all embeds. |
These are great points - I'll add a section to the explainer! Based on the metrics we've collected so far, a non-zero amount of navigations are manual subframe navigations, meaning there are a good chunk of users who click on links in iframes causing them to navigate. And since we believe that styling :visited links is still useful on top-level sites, I think its reasonable to extend that usefulness to these iframes with links as well (i.e. I think these people would notice if they stopped working based on the data I have available).
While the number of subframe navigations is non-zero, it is not close to being the majority of navigations. Again, based on early rough metrics analysis, we estimate that many of the triple-keyed entries will be 1:1 with the previous unpartitioned entries (i.e. we don't expect users to click the same link in all N frames on a top-level site. Potential growth will most likely come from users clicking on the same link from multiple top-level sites, but again, we estimate this to be a small number of navigations.) All this to say - early metrics analysis suggests that triple keying should not produce a significantly larger number of partition keys than double keying.
Absolutely - it will be something we examine closely in future experiments! |
One variation not discussed is to make :visited apply only in main frames and to main frame history entries. I.e. double-key rather than triple-key.
Do you know of legitimate use cases for :visited in iframes? Any idea if anyone would notice if that stopped working? Would that save much in terms of complexity, RAM etc?
I suppose this could always be a potential future signification based on metrics of the cost / benefit tradeoff right?
The text was updated successfully, but these errors were encountered: