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

> Why such limitation? Why does the shadow iframe need to show up in the browser UI?

The rationale for us is that "it works that way without shadow, why do we limit iframe history
would not show up in the browser UI?".

I'd say that having a separate history list for each iframe is a saner design
if we could do from scratch, as you also said, e.g. `history.go()` is very error prone API.
So I tried to have a working proposal, but failed to come up with a solution to provide
consistent behavior when history API in iframe (which has separate history list)
and browser global back/forward button are used.

For us, not including any shadow iframe history in browser UI back/forward button at all is not an option.

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

I thought a similar solution, and but once history API is used in shadow iframes and UI back button is used, it easily went to weird state or weird behavior, and we haven't come up with a clear solution.
If one of the two is exclusively used, it can be very consistent, but both are mixed, it can go some
weird state in a few steps.

Could you have a more formal proposal/algorithm how it sanely works?

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