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

One of the feedback for showing 'back/forward in this frame' in context menu is
that it is hardly discoverable, as `<iframe>`s are not obviously visible to the user,
not to mention whether they are in Shadow or not.
The same could be said to "view source in this frame" etc., but probably back/forward
has more usage.

So I scratched the idea and started looking at how browser's back/forward buttons
interact with navigation in `<iframe>`s.

See this demo (Shadow DOM not included):
https://takayoshikochi.github.io/tests/005_iframes.html

The startpage (A1) has a link to next page (A2), and A2 has 2 `<iframe>`s,
the one loads B1 and the other loads C1.  B1 and C1 has a link to B2 and C2.

As I understand browsers create a history entry for a snapshot of a page including
state of frames.  Let's assume you go to A2 and then navigate C1 to C2, then B1 to B2.
Then browser's back/forward history list contains entries like:

Entry1: A1
Entry2: A2 + B1 + C1
Entry3: A2 + B1 + C2
Entry4: A2 + B2 + C2

Within each frame in the demo, it has 2 buttons (back/forward), which directly calls
`window.history.back()`/`window.history.forward()`. Clicking on any of the 3 "back"
button will navigate to the previous entry in this demo (confirmed on Safari/Firefox/
Chrome on Mac).  Clicking on browser UI "back" button behaves the same.

Next, let's assume those iframe B and C are enclosed in Shadow DOM, and
assume what I proposed previously (https://github.com/w3c/webcomponents/issues/184#issuecomment-212817696 -
separate history list for each `<iframe>`, `history.back()` traverses its own history,
shadow `<iframe>`s do not participate in top-level joint session history).

There are choices how browser UI's back/forward buttons and each frame document's
back/forward buttons.

Question 1: what do browser UI's back/forward buttons work like?

If it should be consistent with`history.back()`/`history.forward()` in the outer frame A,
clicking on UI back button at Entry4 state above will directly go back to page A1 (Entry1).
Or do we keep the same behavior without Shadow DOM, and go back to Entry3 state?
(but `history.back()` would go back to A1 anyway, because session histories of B and C are
not in the joint session history).

Question 2: If the answer to the previous question is the latter (UI back button can navigate
history in shadow `<iframe>`s), and if `history.back()` called in the frame C at Entry4 state
and frame C goes back to C1 from C2.
What should the browser UI back/forward button work?

Possible answer A: a newentry is created with the new state (Entry5) - then
clicking UI back button click will end up going back to Entry4??

Entry1: A1
Entry2: A2 + B1 + C1
Entry3: A2 + B1 + C2
Entry4: A2 + B2 + C2
Entry5: A2 + B2 + C1

Possible answer B: the new history state replaces Entry3. Probably this is broken.

Entry1: A1
Entry2: A2 + B1 + C1
Entry3': A2 + B2 + C1
Entry4: A2 + B2 + C2

Other answers?


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