-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
How should refresh behave with iframes? #6465
Comments
Wow, this is such a simple case, and yet still so non-interoperable... /cc @smaug---- @csreis @natechapin @cdumez to see if we can try to get some cross-browser consensus on what a reasonable behavior is, so that Jake can incorporate it into his session history spec improvement work. Firefox behavior 2 seems kind of nice to me, in the abstract? Firefox behavior 1 is also nice and simple but the back button behavior being bad is unfortunate, and even if that were fixed somehow it would probably be less user-friendly than behavior 2. |
Pretty sure Firefox behavior depends on the order of the loads and not time - whether or not the dynamically added iframe gets loaded (or load gets to a certain point) before or after the static ones. So far I have locally seen only behavior 1. |
Fwiw I've noticed two Firefox behaviours even without a dynamic frame. |
That said, I haven't been able to reproduce "Firefox behaviour 2" today 😭 |
Ok, I saw "Firefox behaviour 2" again, and took a screencap to prove (mostly to myself) that it exists https://www.youtube.com/watch?v=tLPO6icRH3Y |
The test:
https://static-misc-2.glitch.me/iframe-refresh/
Chrome
Reload with all four iframes set to their initial src urls.
Clicking back will navigate the first three iframes, the first one to "one", and the other two to "initial". iframes two and three reload even though they're going to the same URL.
Iframe 4 does not reload.
Clicking forward will navigate all four iframes back to initial. This is weird and asymetrical, and seems to be caused by the 4th iframe being JS-created.
Safari
Same as Chrome, except iframe 4 doesn't have special behaviour – it's treated similar to iframe 3.
I think Chrome and Safari are running their code to remap session history back to iframes, as if they haven't seen them before. Safari does include JS-created iframes in this process, but Chrome doesn't, which may explain what we're seeing here.
Firefox
Firefox changes behaviour, and it feels like time is involved.
Firefox behaviour 1
If I run the above steps in a reasonable time, then Firefox sets all iframes to their initial src urls, but it also discards other history entries related to the page (although the back/forward UI doesn't realise this). This is kinda reasonable behaviour.
Firefox behaviour 2
However, if I leave a few minutes between steps 2 & 3, then Firefox reloads with the first two iframes set to "one" and "two", as in it restores them.
Clicking back navigates just iframe 2 back to "initial", clicking back again navigates just iframe 1 back to "initial". Clicking forward does the reverse.
This is also reasonable behaviour, but it's really really weird that it changes based on time. @annevk help! Who can tell me what's actually going on here?
Correct behaviour
The state that Chrome and Safari get into seems really weird to me. Firefox's multiple-behaviours are even weirder, but either one of those behaviours seem ok. I dunno, I kinda want to just hide under a rock.
The text was updated successfully, but these errors were encountered: