Consider cancelling pending forward navigations when going back

[esprehn]

Queued forward navigations should automatically cancel when executing a backwards navigation.

ex. In the photo gallery example:

1. Start on /photos/2
2. Click Next button which starts a navigation to /photos/3 with pushNewEntry(callback)
3. Navigation event fires and respondWith() starts a 500ms animation
4. Click Next 9 more times queuing 9 callbacks with pushNewEntry(callback)
5. Click Back button taking you to /photos/1
6. No more navigations happen, all 9 callbacks are cancelled.

The expected user behavior is not that the app goes back to /photos/1 and then jumps forward 9 times, but that all pending forward navigations are cancelled whenever going backwards.

I don't think this should be done manually through an AbortSignal. In practice the queued navigations are likely to come out of third party libraries or unrelated components.

[tbondwilkinson]

Could this be handled by the router itself? Or are you suggesting this is universally desirable?

I think the router (which knows about pending navigations) should be responsible for cancelling the push navigations on a back click. I'm not convinced the framework itself should do this behavior.

[esprehn]

@tbondwilkinson I think this does need to be done by the platform because navigations come from multiple uncoordinated libraries on the page.

I'm not sure I understand what you mean by the router knowing about pending navigations. There's no router here, just calls to pushNewEntry() from libraries all over the page. The spec does not expose a way to cancel a navigation, or get the list of pending navigations currently. You could imagine adding that of course, though I think this behavior makes sense as the default because I can't imagine the common scenario is one where users expect queued forward navigations to continue after clicking back. No existing web apps or native apps I'm aware of do that?

[tbondwilkinson]

I do think that most applications will choose to have one central navigate listener installed on the page that will do the basic work of routing, even if there are multiple uncoordinated libraries on the page.

[esprehn]

@tbondwilkinson I think you're misunderstanding the ticket here. The spec provides no facility for that central navigate listener to inspect the pending navigation stack or to cancel a pending navigation. Calls to pushNewEntry() go into a queue you can't interact with. There's also no way to know when the sequence of navigate events comes in should you want to cancel them, and that starts to make the router abstraction fairly complex.

I think requiring a sophisticated router that is observing all forward and backward navigation and picking and choosing what to cancel would be unfortunate and likely leads to a lot of buggy web apps compared to native. I don't think any real app jumps forward like this after going back.

[tbondwilkinson]

Sorry, I'm not being clear.

1. I agree that the spec does not currently provide mechanisms to discard queued navigations. I think that's discussed here: https://github.com/WICG/app-history#queued-up-single-page-navigations, but it's not really fleshed out what the right API is, and there's some todos. So there's definitely work to be done.
2. What I'm trying to respond to is that I'm not sure I agree that it would be right to discard certain queued navigations by default (rather than implementing an API that allows application code to respond to a push by discarding navigations), but I could be convinced with more examples, and as long as there aren't counter-examples where this would prevent applications from doing things that are reasonable.

[tbondwilkinson]

Part of my concern with this is that browsers have chosen different default behaviors for this exact use case today:

https://docs.google.com/document/d/1Pdve-DJ1JCGilj9Yqf5HxRJyBKSel5owgOvUJqTauwU/edit

This is certainly broken. I think the only two choices are making it explicit in the spec, and really spending the time to spell out every edge case, and then making tests to ensure all browsers are consistent, or just punting and making the application do the cancellation.

But I'm starting to come-around to thinking that reasonable defaults is more desirable than making the application router do more work. Certainly less likely to be buggy, as you point out.