Provide initial explanation of session history and navigation #234
Conversation
|
Adding @jakearchibald . PTAL. |
| @@ -189,11 +189,11 @@ Authors should respect the `prefers-reduced-motion` media query by conditionally | |||
|
|
|||
| ### Session history, navigation, and bfcache | |||
|
|
|||
| From the user's perspective, a portal activation behaves like a conventional navigation. The content of the portal is appended to session history with any existing forawrd history entries pruned. Any navigations within a portal do not affect session history. | |||
| From the user's perspective, a portal activation behaves like a conventional navigation. The content of the portal is appended to session history with any existing forward history entries pruned. Any navigations within a portal do not affect session history. | |||
There was a problem hiding this comment.
I guess we might revisit this later?
- Top level page loads with iframe
1.htmland portal1.html. - iframe and portal navigated to
2.html. - Top level page navigates.
- Back.
We're currently saying that the iframe would load 2.html and the portal would load 1.html (unless bfcache is involved).
| @@ -189,13 +189,24 @@ Authors should respect the `prefers-reduced-motion` media query by conditionally | |||
|
|
|||
| ### Session history, navigation, and bfcache | |||
|
|
|||
| From the user's perspective, a portal activation behaves like a conventional navigation. The content of the portal is appended to session history with any existing forward history entries pruned. Any navigations within a portal do not affect session history. | |||
|
|
|||
| From the developer's perspective, a portal context can be thought of as having a trivial [session history](https://html.spec.whatwg.org/multipage/history.html#the-session-history-of-browsing-contexts) where only one entry, the current entry, exists. All navigations within the portal are effectively done with replacement. While APIs that operate on session history, such as [window.history](https://html.spec.whatwg.org/multipage/history.html#the-history-interface), can be called within portal contexts, they only operate on the portal's trivial session history. Consequently, portals cannot navigate their hosts using these APIs, unlike iframes. | |||
There was a problem hiding this comment.
I think it makes sense to spec it like this too.
README.md
Outdated
|
|
||
| We want the history model for portals to conform to users' expectations of the back button. Specifically, the back button should take them back to the last thing they saw. Unfortunately, as mentioned [below](#summary-of-differences-between-portals-and-iframes), the mental model of a portal may differ between users and web developers. While developers will see portals as separate contexts navigating independently from their host context, users will not. This means that the portal context should not have an independent session history which we aggregate with its host context to present to the user. To illustrate how this could cause problems, consider `example.com/a.html` loading `b.html` in a portal, then navigating the portal to `c.html`, then activating the portal. If the user pressed the back button, it would not be appropriate to load `b.html`, since (1) this makes for bad UX as this is a state the user has not seen before and, (2) this is a concern for privacy as the user's browsing history would contain a page they did not intend to visit. Even for states that the user has seen previously, having a single navigation reintroduce potentially multiple history states maps poorly to the web's chronological history model, as opposed to the mental models for tab switching or mobile device style multitasking. | ||
|
|
||
| Navigations within portals are subject to certain security restrictions. Notably, content that does not allow embedding (e.g. via `X-Frame-Options` [see above](#permissions-and-policies)) cannot load in a portal. Furthermore, both the portal host and the portal content must use an HTTP(S) scheme. This is in order to establish the origin of the content for it to be used safely. |
There was a problem hiding this comment.
Do we want to mention that we might introduce a way for content to opt into portal use despite X-Frame-Options?
This is in order to establish the origin of the content for it to be used safely.
Struggling to parse this line.
There was a problem hiding this comment.
I think it might be best to omit this paragraph entirely, given that discussions are still ongoing in #232
There was a problem hiding this comment.
Removed the specific mention of XFO and now just reference the relevant section.
Reworded the bit about origins. If we need explain why origins are important here, we could reference https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/GbVcuwg_QjM%5B1-25%5D , otherwise I can leave it as is.
There was a problem hiding this comment.
That's a good link, but I think it's OK to omit for now.
|
|
||
| Navigations within portals are subject to certain security restrictions. Notably, content that does not allow embedding (e.g. via `X-Frame-Options` [see above](#permissions-and-policies)) cannot load in a portal. Furthermore, both the portal host and the portal content must use an HTTP(S) scheme. This is in order to establish the origin of the content for it to be used safely. | ||
|
|
||
| Navigation errors within portals may cause portal activation to be rejected. Instead of, for example, the user agent showing an error page to the user as with a conventional navigation, the promise returned by the activate method allows a page to gracefully handle the rejection. Furthermore, user agents have existing limitations on navigations initiated by the page where they may be ignored if they are considered to conflict with a user's intent to perform a different navigation. Such cases are not described by the existing navigation spec (see [#218](https://github.com/WICG/portals/issues/218)), but portal activations are subject to these limitations. In the case where another navigation takes precedence over portal activation, the promise returned by the activate method rejects. |
There was a problem hiding this comment.
Navigation errors within portals may cause portal activation to be rejected.
I think that may be exposing something we don't currently expose.
There was a problem hiding this comment.
Worth filing an issue and pointing to it from here, perhaps.
There was a problem hiding this comment.
The same information would be exposed in other ways. For example, |fetch('https://doesnotexist.example.com/')| rejects.
There was a problem hiding this comment.
But you can't tell if that fetch fails because of lack of CORS headers, or because of an actual network error.
There was a problem hiding this comment.
I think there are cases where that isn't true. X-frame-options: DENY wouldn't cause fetch to fail, but it would cause a portal to fail, for instance.
There was a problem hiding this comment.
Oops, I missed issue #228 which talks about this. I'll reference it here for now.
…tory entries Co-authored-by: Jake Archibald <jaffathecake@gmail.com>
README.md
Outdated
|
|
||
| From the developer's perspective, a portal context can be thought of as having a trivial [session history](https://html.spec.whatwg.org/multipage/history.html#the-session-history-of-browsing-contexts) where only one entry, the current entry, exists. All navigations within the portal are effectively done with replacement. While APIs that operate on session history, such as [window.history](https://html.spec.whatwg.org/multipage/history.html#the-history-interface), can be called within portal contexts, they only operate on the portal's trivial session history. Consequently, portals cannot navigate their hosts using these APIs, unlike iframes. | ||
|
|
||
| We want the history model for portals to conform to users' expectations of the back button. Specifically, the back button should take them back to the last thing they saw. To accommodate this, the portal context should not have an independent session history which we aggregate with its host context to present to the user. To illustrate how this could cause problems, consider `example.com/a.html` loading `b.html` in a portal, then navigating the portal to `c.html`, then activating the portal. If the user pressed the back button, it would not be appropriate to navigate the top level page to `b.html`, since this is a state the user has not seen before. Even for states that the user has seen previously, having a single navigation reintroduce potentially multiple history states maps poorly to the web's chronological history model, as opposed to the mental models for tab switching or mobile device style multitasking. |
There was a problem hiding this comment.
| We want the history model for portals to conform to users' expectations of the back button. Specifically, the back button should take them back to the last thing they saw. To accommodate this, the portal context should not have an independent session history which we aggregate with its host context to present to the user. To illustrate how this could cause problems, consider `example.com/a.html` loading `b.html` in a portal, then navigating the portal to `c.html`, then activating the portal. If the user pressed the back button, it would not be appropriate to navigate the top level page to `b.html`, since this is a state the user has not seen before. Even for states that the user has seen previously, having a single navigation reintroduce potentially multiple history states maps poorly to the web's chronological history model, as opposed to the mental models for tab switching or mobile device style multitasking. | |
| We want the history model for portals to conform to users' expectations of the back button. Specifically, the back button should take them back to the last thing they saw. To accommodate this, the portal context should not have an independent session history which we aggregate with its host context to present to the user. To illustrate how this could cause problems, consider `example.com/a.html` loading `b.html` in a portal, then navigating the portal to `c.html`, then activating the portal. If the user pressed the back button, it would not be appropriate to navigate the top level page to `b.html`, since this is a state the user has not seen before. Instead, they navigate the top-level page back to `a.html`, with either `b.html` in the portal (if the back-navigation is a fresh load) or `c.html` in the portal (if the back-navigation uses bfcache). Even for other examples involving states that the user has seen previously, having a single navigation reintroduce potentially multiple history states would map poorly to the web's chronological history model, as opposed to the mental models for tab switching or mobile device style multitasking. |
Is this right?
There was a problem hiding this comment.
Essentially yes. But the adoption/bfcache part is complicated enough that, IMO, it's worth describing separately from the point being made here.
Reworded this a bit.
I'll be OOO until August 4. Feel free to merge if it looks okay while I'm away. |
| - Talk about how bfcache is tricky. | ||
| - Describe reversing transitions on back with bfcache and adopted portals. |
There was a problem hiding this comment.
It's looking less and less likely that readoption (re-adoption, not read-option) will be part of an MVP. If so this might be punted for awhile.
There was a problem hiding this comment.
fwiw I don't think adoption should be required for reverse transitions
The more complicated scenarios still need explanation, but this conveys the overall design.