Re: [w3c/webcomponents] <iframe> and the History API (#184)

> If anyone cannot come up with a way to make it compatible with how back/forward button behaves on current browsers, we cannot mandate the separate list idea in V1.

Why such limitation? Why does the shadow iframe need to show up in the browser UI?
One could also consider (conceptually) navigation in shadow iframes as replacing iframe with a new iframe[1]. That ends up removing the previous entries from session history and just add the new current one. Remember, user doesn't know what an iframe is. One way to consider this all is that, effectively session history is top level page navigations and state changes inside those which user can back<->forward. Iframe navigations are states within the top level page, not much different to pushState. And shadow iframes don't add such states.
([1] Note, webkit/blink are broken when doing dynamic changes. In some cases they end up loading session history entries to browsing contexts which never had such url loaded.
http://mozilla.pettay.fi/moztests/history2/Start.html is an old test for that.)

However if we do want to expose shadow iframe navigations in UI, UI could merge the various session history trees by looking at the creation time of the entries. That is anyhow the approach the HTML spec has taken for the normal DOM.
So, back button would end up checking which session history tree has the previous entry created most recently and navigate that tree.
Whether the shadow iframes should be exposed in the UI should be spec'ed.
Now that I think this some more, this shouldn't be too hard to implement in Gecko.
Session history transaction list would just contain entries for various session histories. And if history.go(...) was used, that would need to skip entries not for that particular session history.
UI would operate on the transaction list in the normal way.


One problem with merging various session history trees in UI is that top level page's history.back()/forward()/go() wouldn't map to it anymore. I guess that is fine.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/184#issuecomment-221837025