Skip to content
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

Merged
merged 22 commits into from
Dec 13, 2023
Merged

Navigation API : "activation info" #9856

merged 22 commits into from
Dec 13, 2023

Conversation

noamr
Copy link
Contributor

@noamr noamr commented Oct 16, 2023

Add support for navigation.activation and the NavigationActivation interface
Closes #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 and navigation.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.

(See WHATWG Working Mode: Changes for more details.)


/browsing-the-web.html ( diff )
/index.html ( diff )
/nav-history-apis.html ( diff )

@noamr noamr changed the title Activation info WIP Activation info Oct 16, 2023
@noamr noamr changed the title WIP Activation info Navigation API : "activation info" Oct 16, 2023
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
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>
Copy link
Member

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.

Copy link
Contributor Author

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.

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
Copy link
Member

@domenic domenic left a 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.

source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
@noamr
Copy link
Contributor Author

noamr commented Oct 19, 2023

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.

Copy link
Member

@domenic domenic left a 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 Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated
<p>Switch on <var>navigationType</var>:</p>

<dl class=switch>
<dt>"<span data-x="dom-NavigationType-reload">reload</span>"</dt>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still to be done.

source Show resolved Hide resolved
@noamr
Copy link
Contributor Author

noamr commented Oct 20, 2023

@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?

source Show resolved Hide resolved
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 31, 2023
Initial discussion: whatwg/html#9760
Draft spec PR: whatwg/html#9856

Bug: 1492932
Change-Id: I2e090a8366906e4cb6778893ad9ffdca18d6ec37
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Nov 22, 2023
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
vinnydiehl pushed a commit to vinnydiehl/mozilla-unified that referenced this pull request Nov 24, 2023
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
vinnydiehl pushed a commit to vinnydiehl/mozilla-unified that referenced this pull request Nov 24, 2023
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
@saschanaz
Copy link
Member

The name is a bit confusing to me given there is navigator.userActivation, can this be documentActivation or such?

@domenic
Copy link
Member

domenic commented Dec 12, 2023

The name is a bit confusing to me given there is navigator.userActivation, can this be documentActivation or such?

I would be a bit sad about this. I think navigation and navigator are separate enough, and it's not clear what else you'd be activating during a navigation...

@domenic domenic added addition/proposal New features or enhancements topic: navigation labels Dec 12, 2023
<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>

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@smaug----
Copy link

The name is a bit confusing to me given there is navigator.userActivation, can this be documentActivation or such?

I don't feel navigation.activation is too confusing. It is after all a property of the navigation object.

@noamr
Copy link
Contributor Author

noamr commented Dec 12, 2023

The name is a bit confusing to me given there is navigator.userActivation, can this be documentActivation or such?

I would be a bit sad about this. I think navigation and navigator are separate enough, and it's not clear what else you'd be activating during a navigation...

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.

@saschanaz
Copy link
Member

The only different part between two is or.userA and ion.a which is enough for me to be confused, but if it's not for others, then fine.

@noamr
Copy link
Contributor Author

noamr commented Dec 12, 2023

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

@domenic domenic merged commit da3a62e into whatwg:main Dec 13, 2023
2 checks passed
mobounya pushed a commit to mobounya/ladybird that referenced this pull request Jul 21, 2024
Update 'update_for_history_step_application' to meet some of the specs
introduced in whatwg/html#9856 and in
whatwg/html#9990
mobounya pushed a commit to mobounya/ladybird that referenced this pull request Jul 21, 2024
Update 'update_for_history_step_application' to meet some of the specs
introduced in whatwg/html#9856 and in
whatwg/html#9990
mobounya pushed a commit to mobounya/ladybird that referenced this pull request Jul 21, 2024
Update 'update_for_history_step_application' to meet some of the specs
introduced in whatwg/html#9856 and in
whatwg/html#9990
mobounya pushed a commit to mobounya/ladybird that referenced this pull request Jul 21, 2024
Update 'update_for_history_step_application' to meet some of the specs
introduced in whatwg/html#9856 and in
whatwg/html#9990
mobounya pushed a commit to mobounya/ladybird that referenced this pull request Jul 21, 2024
Update 'update_for_history_step_application' to meet some of the specs
introduced in whatwg/html#9856 and in
whatwg/html#9990
mobounya pushed a commit to mobounya/ladybird that referenced this pull request Jul 22, 2024
Update 'update_for_history_step_application' to meet some of the specs
introduced in whatwg/html#9856 and in
whatwg/html#9990
kalenikaliaksandr pushed a commit to LadybirdBrowser/ladybird that referenced this pull request Jul 22, 2024
Update 'update_for_history_step_application' to meet some of the specs
introduced in whatwg/html#9856 and in
whatwg/html#9990
circl-lastname pushed a commit to circl-lastname/serenity that referenced this pull request Jul 22, 2024
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)
nico pushed a commit to SerenityOS/serenity that referenced this pull request Jul 22, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements topic: navigation
Development

Successfully merging this pull request may close these issues.

Expose information about last activation/cross-document navigation
6 participants