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
Add test for Joint session state manipulation #16381
Add test for Joint session state manipulation #16381
Conversation
Some browers don't seem to agree on how top-level container should handle the navigation of the child, particularly around if the state should be overwritten by the child or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If push state history is indeed per global this looks correct to me. It would be nice to assert the child's state before you navigate it as well.
@cdumez you probably wanna look at this and comment regarding WebKit's perspective.
html/browsers/history/joint-session-history/joint-session-history-iframe-state.html
Outdated
Show resolved
Hide resolved
(Forgot to say I really appreciate your work on this @jutaz!) |
Can do 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll leave this open for a bit to let @cdumez comment, but do ping again if you feel like you've been waiting too long and I'll get it merged. Thanks again!
Thanks @annevk! I'd love to hear from Webkit's team, so all good for now 👍 |
Bumping this - would love to get this merged 🙏 |
Thanks @annevk! |
Some browsers don't seem to agree on how top-level container should handle the navigation of the child, particularly around if the state should be overwritten by the child or not. This is particularly prominent in WebKit based browsers, such as Safari.
As far as I've tested this, it appears that these browsers pass the test:
These browsers don't pass the test:
This leads me to believe that Chrome & Firefox's implementation is correct, thus this test is geared to pass in these browsers. Ideally we'd follow the
history
spec, but as far as I'm aware, it does not specify how browsers should work in this particular scenario.Looking at this pragmatically as well, it appears that keeping the
window.history.state
in the navigation makes sense, as the top window did not actually change it's state, just the child iframe, even if navigation occurred and going back in history means that child iframe will navigate back. That, however, does not alter the state of the parent window, which is why it appears that implementation in Chrome/Firefox seems correct.References