-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navigation API : "activation info" #9856
Conversation
source
Outdated
@@ -99509,6 +99577,29 @@ location.href = '#foo';</code></pre> | |||
data-x="nav-active-history-entry">active session history entry</span>.</p> | |||
</li> | |||
|
|||
<li> | |||
<p>Let <var>activationNavigationType</var> be determined as follows:</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, this is just further evidence I really should pass in the NavigationType to this algorithm (instead of requiring it to be re-computed).
The initial ideal was that we would just set things up nicely, and "apply the history step" would behave basically the same, with no special casing needed for each type.
However, as noted in #9826 (see especially my reply), this is not working out great. And we have the wrapper algorithms anyway, so this purity is not helping.
An important thing to note is that "apply the history step" can be called for something which is none of these four types: https://html.spec.whatwg.org/#update-for-navigable-creation/destruction . I think this breaks your switch here.
So here's my proposal. We add a NavigationType to "apply the history step", and thread it through from all calling algorithms. (This is slightly more involved for "apply the push/replace history step".) Ideally we fix #9826 as part of this. Then, we can just use it and not re-compute it here.
Maybe we can even add some asserts, that parallel the great work you've done here to re-derive the state from the other parameters. Or maybe we could delete the "reload pending" and "ever populated" flags!! That would be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here's my proposal. We add a NavigationType to "apply the history step", and thread it through from all calling algorithms. (This is slightly more involved for "apply the push/replace history step".)
Then, we can just use it and not re-compute it here.
Done
Ideally we fix #9826 as part of this.
I think that would have to be a next step on top of this.
Maybe we can even add some asserts, that parallel the great work you've done here to re-derive the state from the other parameters.
Done
Or maybe we could delete the "reload pending" and "ever populated" flags!! That would be nice.
Not just yet unfortunately... still needed for putting all kind of parameters on the request.
f5a025a
to
bb9ad3e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks solid! Only substantial thing I'm unsure about is whether the null navigationType case is handled.
Yea it can be null when creating the navigable, clarified that we're not creating the activation object in that case. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with nits (and a bikeshed question).
source
Outdated
<p>Switch on <var>navigationType</var>:</p> | ||
|
||
<dl class=switch> | ||
<dt>"<span data-x="dom-NavigationType-reload">reload</span>"</dt> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still to be done.
@zcorpan Is this something that needs a new "standards position" or do you want to look at this as a detail of the navigation API? |
Initial discussion: whatwg/html#9760 Draft spec PR: whatwg/html#9856 Bug: 1492932 Change-Id: I2e090a8366906e4cb6778893ad9ffdca18d6ec37
Automatic update from web-platform-tests NavigationActivation prototype (#42873) NavigationActivation is a new object (exposed as `navigation.activation`). It is updated when a new Document is "activated": initial Document creation, restore from bfcache, or (in a future CL) prerender activation. It has three pieces of state: * `activation.entry`: The current NavigationHistoryEntry at the time of activation. * `activation.from`: The current NavigationHistoryEntry immediately before activation (i.e., the entry we came from). This will be null if the navigation was cross-origin, or if the previous entry was not in the same-origin contiguous region of the back/forward list that is available in `navigation.entries()`. * `activation.navigationType`: The navigationType ('push', 'replace', 'reload', or 'traverse') of the navigation that activated the current Document. Note that `entry` or `from` may be a NavigationHistoryEntry that is no longer present in `navigation.entries()` (e.g., when doing a replace navigation, `activation.from` will be the replaced entry). In that case, the entry will remain visible, but because it is a "disposed" entry, its index will be -1 and attempting to `navigation.traverseTo()` its key will be rejected. Initial discussion: whatwg/html#9760 Draft spec PR: whatwg/html#9856 I2p: https://groups.google.com/a/chromium.org/g/blink-dev/c/EfqxeH3Iwh4 Bug: 1492932 Change-Id: I2e090a8366906e4cb6778893ad9ffdca18d6ec37 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4990011 Reviewed-by: Domenic Denicola <domenic@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/main@{#1220983} Co-authored-by: Nate Chapin <japhet@chromium.org> -- wpt-commits: c2ca6ebdc7f92fbaf7308c91dda05bcaf24ef455 wpt-pr: 42873
Automatic update from web-platform-tests NavigationActivation prototype (#42873) NavigationActivation is a new object (exposed as `navigation.activation`). It is updated when a new Document is "activated": initial Document creation, restore from bfcache, or (in a future CL) prerender activation. It has three pieces of state: * `activation.entry`: The current NavigationHistoryEntry at the time of activation. * `activation.from`: The current NavigationHistoryEntry immediately before activation (i.e., the entry we came from). This will be null if the navigation was cross-origin, or if the previous entry was not in the same-origin contiguous region of the back/forward list that is available in `navigation.entries()`. * `activation.navigationType`: The navigationType ('push', 'replace', 'reload', or 'traverse') of the navigation that activated the current Document. Note that `entry` or `from` may be a NavigationHistoryEntry that is no longer present in `navigation.entries()` (e.g., when doing a replace navigation, `activation.from` will be the replaced entry). In that case, the entry will remain visible, but because it is a "disposed" entry, its index will be -1 and attempting to `navigation.traverseTo()` its key will be rejected. Initial discussion: whatwg/html#9760 Draft spec PR: whatwg/html#9856 I2p: https://groups.google.com/a/chromium.org/g/blink-dev/c/EfqxeH3Iwh4 Bug: 1492932 Change-Id: I2e090a8366906e4cb6778893ad9ffdca18d6ec37 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4990011 Reviewed-by: Domenic Denicola <domenic@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/main@{#1220983} Co-authored-by: Nate Chapin <japhet@chromium.org> -- wpt-commits: c2ca6ebdc7f92fbaf7308c91dda05bcaf24ef455 wpt-pr: 42873
Automatic update from web-platform-tests NavigationActivation prototype (#42873) NavigationActivation is a new object (exposed as `navigation.activation`). It is updated when a new Document is "activated": initial Document creation, restore from bfcache, or (in a future CL) prerender activation. It has three pieces of state: * `activation.entry`: The current NavigationHistoryEntry at the time of activation. * `activation.from`: The current NavigationHistoryEntry immediately before activation (i.e., the entry we came from). This will be null if the navigation was cross-origin, or if the previous entry was not in the same-origin contiguous region of the back/forward list that is available in `navigation.entries()`. * `activation.navigationType`: The navigationType ('push', 'replace', 'reload', or 'traverse') of the navigation that activated the current Document. Note that `entry` or `from` may be a NavigationHistoryEntry that is no longer present in `navigation.entries()` (e.g., when doing a replace navigation, `activation.from` will be the replaced entry). In that case, the entry will remain visible, but because it is a "disposed" entry, its index will be -1 and attempting to `navigation.traverseTo()` its key will be rejected. Initial discussion: whatwg/html#9760 Draft spec PR: whatwg/html#9856 I2p: https://groups.google.com/a/chromium.org/g/blink-dev/c/EfqxeH3Iwh4 Bug: 1492932 Change-Id: I2e090a8366906e4cb6778893ad9ffdca18d6ec37 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4990011 Reviewed-by: Domenic Denicola <domenic@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/main@{#1220983} Co-authored-by: Nate Chapin <japhet@chromium.org> -- wpt-commits: c2ca6ebdc7f92fbaf7308c91dda05bcaf24ef455 wpt-pr: 42873
The name is a bit confusing to me given there is |
I would be a bit sad about this. I think |
<dd> | ||
<p>A <code>NavigationHistoryEntry</code>, representing the <code>Document</code> that was active | ||
right before the current <code>Document</code>. This might have a value null in case the | ||
previous <code>Document</code> was not <span>same origin</span> with this one.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"might" is a bit confusing here. Is the value null or is it not when the previous document was cross origin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's null in that case... will reword.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
I don't feel navigation.activation is too confusing. It is after all a property of the navigation object. |
I feel the same, I think the name is clear enough. There are plenty of reused words in the web platform, and without the word "user" this is distinct enough. |
The only different part between two is |
@domenic I think we're good to go? You've already approved and now that Mozilla gave a thumbs up all the checkboxes are ticket. Of course another pass is always welcome as well. |
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990 (cherry picked from commit 2497f43989af3efa695d0d33de59001cb87bacb6)
Update 'update_for_history_step_application' to meet some of the specs introduced in whatwg/html#9856 and in whatwg/html#9990 (cherry picked from commit 2497f43989af3efa695d0d33de59001cb87bacb6)
Add support for
navigation.activation
and theNavigationActivation
interfaceCloses #9760
Upon activating a new document in place of an old one (a cross-document navigation), we save an old and new
NavigationHistoryEntry
objects to be accessible, and also the navigation type.This is accessible via
navigation.activation.from
,navigation.activation.entry
andnavigation.activation.navigationType
.The initial use case for this is CSS view transitions - being able to curate/customize the transitions based on "where did we come from and how", which is information that's currently not available in an ergonomic way for cross-document navigations. See #9760 for discussion.
navigation.activation
APII mdn/mdn#491(See WHATWG Working Mode: Changes for more details.)
/browsing-the-web.html ( diff )
/index.html ( diff )
/nav-history-apis.html ( diff )