Skip to content
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

Need a concept for closed browsing contexts for bfcache #4428

Closed
annevk opened this issue Mar 12, 2019 · 3 comments · Fixed by #6315
Closed

Need a concept for closed browsing contexts for bfcache #4428

annevk opened this issue Mar 12, 2019 · 3 comments · Fixed by #6315

Comments

@annevk
Copy link
Member

annevk commented Mar 12, 2019

I initially thought we needed another state only due to the work happening in #3740, but it turns out that child browsing contexts can actually be preserved when navigating. How else could you navigate back with them still being there? (Thanks Nika for pointing this out!)

They mostly need to behave identically to discarded browsing contexts, except that we cannot actually discard them. (I don't have a complete understanding of when the difference matters. It's mostly that they still need to be there.)

(To be clear, this "closed" concept is slightly different from the "is closing" concept, which is solely relevant for close(). And it's reversible in that the browsing context can be "opened" again.)

cc @mystor @bzbarsky

@domenic
Copy link
Member

domenic commented Mar 4, 2022

What would this state be used for? I think the fact that the documents are not fully active causes the right consequences for descendants of bfcached pages, usually.

@annevk
Copy link
Member Author

annevk commented Mar 11, 2022

It's not so much about state, it's more that the current model doesn't support this, as far as I can tell. How are they kept around? (See also the other issue where we discussed about the owner of nested browsing contexts.)

@domenic
Copy link
Member

domenic commented Mar 14, 2022

Ah, I see. In that case this too is solved by #6315, since "document's browsing context" after the rewrite becomes a strong reference instead of an indirect one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants