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

In summary, here are options:
3. `<iframe>` in Shadow DOM doesn't participate in parent's session history (no joint)
3.1 such `<iframe>` has its own session history list. `history.go()/back()/forward()` follows the list.
3.2 such `<iframe>` doesn't have its own session history list. `history.go()/back()/forward()` won't work, except `history.go(0)`. (probably `pushState()/replaceState()` won't, either)

3.1:
pro: from the scripting perspective, it cleanly separates the session history, no leak.
con: breaks browser's back/forward buttons in a weird way once navigation is done in shadow iframe via History API (if browser implementation still keeps the joint session history from the whole frame tree and use it for back/forward navigation, as described in my previous comments)

3.2:
pro: can maintain browser back/forward button behvaior, as usage of any history API won't navigate
con: embedded page doesn't know whether history API restriction exists, and some may be broken.

One solution for the con of 3.1 could be that browser UI back/forward buttons don't follow the internal joint session history from the whole frame tree, but use the joint session history of top-level browsing context in the new world (i.e. session history exposed to the top-level `window.history`).
Quoting https://github.com/w3c/webcomponents/issues/184#issuecomment-184904115 from @smaug---- 

> what should back button do? I guess nothing. That shouldn't be too bad.

But this is with the downside that the browser back/forward behavior is different from
when `<iframe>` is used in light DOM.

Implementation feedback for 3.1 (specific to Chrome/Blink) is that lots of current code assumes the joint session history and the top-level page has 1:1 mapping, quite a lot of rework has to be done to separate the list, and UX breakage of browser back/forward buttons is anticipated.

---
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-220281808

Received on Thursday, 19 May 2016 10:06:40 UTC