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

We understand your concern.

The point we'd argue is that "history API usages cause unexpected behavior" (current behavior) vs "splitting session history for shadow iframes causes unexpected behavior for browser UI back/forward navigation".

As I understand, no one has come up with a clear solution to the question posed in https://github.com/w3c/webcomponents/issues/184#issuecomment-219905487.
(I tried in several comments but failed, which is a shame)

In @smaug---- 's https://github.com/w3c/webcomponents/issues/184#issuecomment-221837025

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

"UI would operate on the transaction list" is the tricky part.
For example, when an iframe did `history.go(-1)`, it would create a new transaction.
Then UI back button would forward the iframe?

I don't think there are infinite options how UI back button would behave in this case,
but there are only a few possible ways.  As far as we explored for Blink, they were either
too complex to implement (if not impossible) or more confusing behavior to users.

The most plausible idea I came up with was that such separated session history for
shadow iframes would not be added to the list for UI back/forward button.  This turned
out to be implementable, but I got comments internally that users would get confused.

So we are comparing cost/benefit of implementing the session history split vs
keeping the current behavior.

Keeping the current behavior, basically no cost, but has negative benefit that you already
mentioned several times. Pro is that there is no change in iframe and history API behavior,
in a sense.

On the other hand, splitting the session history, we foresee some non-ignorable implementation
cost (plus cost for inventing/defining a reasonable behavior), clear benefit for encapsulation,
and uncertain con for unexpected inconsistency for UI back/forward button behavior.

We are in the pragmatic position to favor the former.

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

I'd agree that UI back/forward list and top-level session can diverge, but this is not the
point we are against.

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