Fire the pageswap event when navigating away from a document

[noamr]

Together with w3c/csswg-drafts#9819.

The pageswap event is specified here to work as folows:

• It's sent whenever a document navigates away, to a different document, but not when unloaded for other reasons, such as closing the browser types or unloading an ancestor.
• It includes a NavigationActivation object for same-origin navigations.
• If the navigation might trigger a cross-document view-transition (this is determined when snapshotting the source document, by reading the CSS), pageswap is fired and then unloading is deferred until the old state is captured for the view-transition or immediately if the ViewTransition is skipped.

Closes #9702

• At least two implementers are interested (and none opposed):
  • Chromium (implementin)
  • Gecko
• Tests are written and can be reviewed and commented upon at:
  • blink: Fire pageconceal for non-ViewTransition navigations. web-platform-tests/wpt#44714 (note that those still the old pageconceal name, will rename once the spec settles)
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/41495176
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1881438
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=269904
• MDN issue is filed: Document the pageswap event mdn/mdn#528
• The top of this comment includes a clear commit message to use.

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

---

/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/nav-history-apis.html ( diff )
/sections.html ( diff )
/webappapis.html ( diff )

[khushalsagar]

LGTM. Some minor comments about renames and clean up from removing userInitiated from the event.

[khushalsagar]

Seems much simpler now, thanks!

[domenic]

All the hard parts look good!

[domenic]

LGTM.

It occurs to me that maybe it would be cleaner to create separate algorithms instead of the many closures. (Namely the closures for firePageSwap, unloadSteps, everything inside "Otherwise, queue a global task on the navigation and traversal task source given navigable's active window to run the steps:".) That might help keep the overall complexity of reading the algorithm from top to bottom contained.

However, doing so would require adding a good amount of parameters to those separate algorithms (to correspond to the various closed-over variables). And I'm not sure the end result would be that much better, especially since the algorithm is already huge. So, definitely not a blocker for this PR. Just something I'm curious to get your impression of.

[noamr]

LGTM.

It occurs to me that maybe it would be cleaner to create separate algorithms instead of the many closures. (Namely the closures for firePageSwap, unloadSteps, everything inside "Otherwise, queue a global task on the navigation and traversal task source given navigable's active window to run the steps:".) That might help keep the overall complexity of reading the algorithm from top to bottom contained.

However, doing so would require adding a good amount of parameters to those separate algorithms (to correspond to the various closed-over variables). And I'm not sure the end result would be that much better, especially since the algorithm is already huge. So, definitely not a blocker for this PR. Just something I'm curious to get your impression of.

I'm thinking that perhaps we should keep the closure style, but use something like labels or list/details to make it easier to read?

[domenic]

Eh, the main thing I was hoping to get was the ability to read the algorithms top to bottom. So moving from closures to standalone functions would be a form of https://refactoring.guru/extract-method