Should we fire navigate for cross-document history.back()?

[domenic]

(All of this applies to forward as well as back, but I'll only mention back for simplicity.)

The current table has slightly divergent entries for history.back() vs. browser-UI-initiated back navigations. Summarizing:

• Browser back, same-document: cancelable = false, canRespond = true
  • Rationale: cancelable = false prevents back-trapping. But see Cancelling UI initiated navigations (back/forward) #32.
• Browser back, cross-document: no event
  • Rationale: cancelable = false per above, and canRespond = false because we can't let you convert cross-document history traversals into same-document ones. So, don't fire the event, since it's not actionable.
• history.back(), same-document: cancelable = true, canRespond = true
  • Rationale: unlike browser back, back-trapping prevention isn't important
• history.back(), cross-document: cancelable = true, canRespond = false
  • Rationale: unlike browser back, back-trapping prevention isn't important, so the event can fire and be canceled

Since this design, a couple of data points have come up:

• @natechapin reports that distinguishing history.back() from browser back is currently hard in Chrome, so it'd be kind of nice if we didn't have to.

• As part of the discussions in Probably don't allow interception of navigations from other documents #75, we realized that history.back() might originate from another frame, and letting that be canceled could be weird. Although it doesn't have the security difficulty discussed there of exposing the navigated-to URL, it might be good to treat the situations similarly.

These might lean toward something more conservative like making history.back() behave the same as browser back: never cancelable, and no event at all when it's cross-document:

• Browser back, same-document: cancelable = false, canRespond = true
• Browser back, cross-document: no event
• history.back(), same-document: cancelable = false, canRespond = true
• history.back(), cross-document: no event

However, #32's use case of allowing pages to show "are you sure you want to leave?", and in particular some of the latest ideas in #32 (comment), tugs us in a different direction, even if we did want to unify: something like

• Browser back, same-document: cancelable = true once per user activation, canRespond = true
• Browser back, cross-document: cancelable = true once per user activation, canRespond = false
• history.back(), same-document: cancelable = true once per user activation, canRespond = true
• history.back(), cross-document: cancelable = true once per user activation, canRespond = false

And at that point tying history.back() to user activation seems pretty strange, so I'd suggest

• Browser back, same-document: cancelable = true once per user activation, canRespond = true
• Browser back, cross-document: cancelable = true once per user activation, canRespond = false
• history.back(), same-document: cancelable = true, canRespond = true
• history.back(), cross-document: cancelable = true, canRespond = false

and none of the above ideas even start taking into account the initiator, per #75.

So: I'm considering this blocked on #32 and #75 for now.

[tbondwilkinson]

I agree that history.back() should be equivalent to pressing the back button. The distinction between app vs user initiator is probably overly complicated for limited benefit.

Can people use the beforeUnload handler and associated dialog to satisfy #32?

Do we fire other events, besides navigate, for these cases, to enable users to cache resources before the page unloads? Or would we expect that to also be part of an beforeUnload handler?

[domenic]

Can people use the beforeUnload handler and associated dialog to satisfy #32?

Not currently, as beforeunload only works for cross-document navigations. We would need to invent some new kind of single-page beforeunload for the cases described there.

Do we fire other events, besides navigate, for these cases, to enable users to cache resources before the page unloads? Or would we expect that to also be part of an beforeUnload handler?

I think we have plenty of events in the same-document case. And in the cross-document case, yeah, the usual pagehide/beforeunload/unload events seem good to me.

[tbondwilkinson]

To me, it's illogical to add have a respondable event that's not cancellable - because if you can respond to a thing and defer its resolution indefinitely, you should be able to prevent it entirely.

But I would defer to the security folks for what they're comfortable with, who I assume you're talking to in #32.

[domenic]

In my opinion it's very different. If you respond to a back navigation, the back navigation still goes through: you just change the contents of the page that is displayed, i.e. you make it a single-page navigation. Whereas, canceling it stops the back navigation, and leaves you in the current place in the history stack.

[tbondwilkinson]

I mean from an abuse perspective.

If I use respondWith and just leave the promise unresolved, that's a weird user UI too - because it looks like the page is forever loading.

But I suppose you're right, if they click back again they're not trapped