Rough history traversal algorithm #250
Conversation
| @@ -233,6 +233,8 @@ Navigations within portals are subject to certain security restrictions for load | |||
|
|
|||
| 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. | |||
|
|
|||
| See the [rough algorithms](history-traversal.md) for cases where portals may be auto-activated, and pages may be reportaled, when traversing session history. | |||
There was a problem hiding this comment.
Is this the right way to link to another doc from a README.md?
history-traversal.md
Outdated
|
|
||
| ## Activate a portal in a 'push' style | ||
|
|
||
| This is a regular activation that clears any 'forward' items in join session history and adds a new top-level history entry for the portaled document. |
There was a problem hiding this comment.
here and elsewhere, is this "joint"?
| ## Definitions | ||
|
|
||
| <dl> | ||
| <dt>Navigable</dt> |
There was a problem hiding this comment.
i.e., a browsing context?
There was a problem hiding this comment.
Portals can navigate, and when they do so they change browsing context each time.
If you navigate and it requires isolation due to COOP+COEP, that also involves a change in browsing context.
This is one of the "boil the ocean" things that needs to happen, because the spec doesn't carter for this at all, it assumes that browsing contexts stay constant within navigable. The spec also makes session history a property of the browsing context, which is similarly broken.
history-traversal.md
Outdated
|
|
||
| Note: To avoid multiple levels of reportaling, reportaling and implicit activation is skipped if the navigation spans across multiple documents | ||
|
|
||
| 1. Asset: _documentChangesInDelta_ is not 0. |
history-traversal.md
Outdated
| 1. For each item in the navigable's session history, remove its document if the document is _documentToPortal_, and give it a weak reference to _documentToPortal_. | ||
| 1. Otherwise, unload the current history item's document. | ||
|
|
||
| Note: This may include excluding it from bfcache. |
There was a problem hiding this comment.
I don't quite follow this but I assume there's a reason.
There was a problem hiding this comment.
I'll improve the language here. During unloading, things can happen that exclude the document from bfcache, such as unload event handlers.
| 1. Let _document_ be the portal's session history item's document. | ||
| 1. Let _targetHistoryItem_ be a copy of the portal's session history item. | ||
| 1. Remove _targetHistoryItem_'s document. | ||
| 1. Give _targetHistoryItem_ a weak reference to _document_. |
There was a problem hiding this comment.
Is this actually easier/clearer than having the history item has a strong/weak flag rather than two separate fields?
There was a problem hiding this comment.
This isn't as easy as I thought.
Good bits:
- Avoids moving the document from property to property
- Avoids cases where the weak document and main document are set at the same time (and are different)
Less good bits:
- Maybe the moving solidifies the 'documents move around model' that we agreed on?
- It doesn't work with portals. With portals the history item is removed upon activation, so the weak reference is on the portal itself. We could keep the history item and set the weak flag there, but that means any portal rendering/interaction code would need to treat the history entry as absent if the weak flag is set. Although, this would ensure the weak reference is gone when the portal is navigated.
There may be other places where we'd need to avoid doing things with the session history item if the document reference is weak.
I'm undecided.
No description provided.