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.

Sign up for GitHub

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

Jump to bottom

Navigate events for traversals #178

Closed
domenic opened this issue Oct 25, 2021 · 0 comments · Fixed by #182
Closed

Navigate events for traversals #178

domenic opened this issue Oct 25, 2021 · 0 comments · Fixed by #182

Comments

@domenic
Copy link
Collaborator

domenic commented Oct 25, 2021

This is somewhat of a meta-issue for #78 and #32. In particular I want to discuss (a) what we should spec and work toward shipping in a useful v1; (b) what we should leave room for in the future.

The problem space under discussion is, given various traversals, which of them should fire navigate, and which should be preventDefault()able (cancelable) or transitionWhile()able (canTransition)? The current spec has one answer (summarized in the big table) but we're not that happy with it:

  • The current spec is hard to implement, because it tries to make the event cancelable for any programmatic traversal---including ones initiating from other frames. Making this work involves the initiating frame asking all the frames involved "did someone cancel your navigate event?" and collating that information, which is a good bit of engineering work in modern multi-process browsers.

  • The current spec is not solving all the use cases, because it doesn't fire a cancelable event for browser UI traversals, whereas per Cancelling UI initiated navigations (back/forward) #32 people want a cancelable navigate event for those so they can say "are you sure you want to leave this page?"

After talking with @japhet, here is our alternate proposal:

  • For "v1": fire a navigate event for all traversals. It is never cancelable for traversals, and it is canTransition only for same-document traversals.

  • For "v1.1": do the extra engineering work to make the event cancelable for all programmatic traversals. And, per the latest discussion in Cancelling UI initiated navigations (back/forward) #32, also make it cancelable for browser UI traversals when there has been user activation. (No change to canTransition.)

Notably, we think it's important that in v1 we always fire the navigate event, even if it's neither cancelable nor canTransition. The current spec does not fire the event in such scenarios, since it's a little useless, but that could create a forward-compatibility problem in the future if the event starts firing when pages aren't expecting it.

What do folks think?
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 1, 2021
@natechapin @chromium-wpt-export-bot
Update AppHistory navigate event behavior for traversals
60600fb 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  same-document and for cross-document appHistory.goTo(), but not
  cross-document traversals from the legacy history API, or from the UI.
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Merged
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 1, 2021
@natechapin @chromium-wpt-export-bot
Update AppHistory navigate event behavior for traversals
ee2b057 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 1, 2021
@natechapin @chromium-wpt-export-bot
Update AppHistory navigate event behavior for traversals
a5f4f5f 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 2, 2021
@natechapin @chromium-wpt-export-bot
Update AppHistory navigate event behavior for traversals
03c81b7 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 3, 2021
@natechapin @chromium-wpt-export-bot
Update AppHistory navigate event behavior for traversals
233a9f3 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 3, 2021
@natechapin @chromium-wpt-export-bot
Update AppHistory navigate event behavior for traversals
b0f4d97 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255177
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#937981}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 3, 2021
@natechapin @chromium-wpt-export-bot
Update AppHistory navigate event behavior for traversals
e637041 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255177
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#937981}
pull bot pushed a commit to Alan-love/chromium that referenced this issue Nov 4, 2021
@natechapin
Update AppHistory navigate event behavior for traversals
87021c0 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255177
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#937981}
domenic added a commit that referenced this issue Nov 4, 2021
@domenic
Simplify navigate event firing for now
67a052c 
Closes #178 by implementing the conclusion there, of firing non-cancelable navigate events for all traversals.
domenic added a commit that referenced this issue Nov 4, 2021
@domenic
Simplify navigate event firing for now
8a9d1c7 
Closes #178 by implementing the conclusion there, of firing non-cancelable navigate events for all traversals.
@domenic domenic mentioned this issue Nov 4, 2021
Merged
domenic added a commit that referenced this issue Nov 4, 2021
@domenic
Simplify navigate event firing for now
93d16a0 
Closes #78 and closes #178 by implementing the conclusion in the latter, of firing non-cancelable navigate events for all traversals. #32 remains open as a desired future feature, and is now explicitly called out as such in the README.
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 10, 2021
@natechapin @moz-wptsync-bot
Bug 1738739 [wpt PR 31459] - Update AppHistory navigate event behavio…
83bfef3 
…r for traversals, a=testonly

Automatic update from web-platform-tests
Update AppHistory navigate event behavior for traversals

Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255177
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#937981}

--

wpt-commits: e637041005202690b5cf3be09bd4056f80fce2be
wpt-pr: 31459
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Nov 10, 2021
@natechapin @moz-wptsync-bot
Bug 1738739 [wpt PR 31459] - Update AppHistory navigate event behavio…
1062507 
…r for traversals, a=testonly

Automatic update from web-platform-tests
Update AppHistory navigate event behavior for traversals

Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255177
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#937981}

--

wpt-commits: e637041005202690b5cf3be09bd4056f80fce2be
wpt-pr: 31459
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this issue Nov 18, 2021
@natechapin @Gabisampaio
Update AppHistory navigate event behavior for traversals
5a95d77 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255177
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#937981}
@domenic domenic mentioned this issue Mar 18, 2022
Closed
@domenic domenic mentioned this issue May 24, 2022
Open
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
@natechapin @copybara-github
Update AppHistory navigate event behavior for traversals
d8518a9 
Follows WICG/navigation-api#178

* Always fire navigate event for traversals (currently, we fire it for
  all same-document traversals and for cross-document appHistory.goTo(),
  but not cross-document traversals from the legacy history API, or
  from the UI).
* The AppHistory navigate event should never be cancelable for
  traversals. Previously, it was cancelable for renderer-initiated
  traversals, but this has the potential to cause problems in the case
  where multiple frames are navigating and one frame (but not all)
  cancels. That frame would be out of sync with the authoritative
  history state in the browser process.

Change-Id: I92a3ee0f908acc04c31dc9b8ec57569bd66b4bc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255177
Reviewed-by: Domenic Denicola <[email protected]>
Commit-Queue: Nate Chapin <[email protected]>
Cr-Commit-Position: refs/heads/main@{#937981}
NOKEYCHECK=True
GitOrigin-RevId: 87021c0d80a703df61dd68a34eec72c1517b9c17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Simplify navigate event firing for now WICG/navigation-api
1 participant
@domenic