Web viewer navigation (back-button)

[jprochazk]

We currently don't handle back/forward navigations in any way.

In practice, this means that:

• A user sees a link to our web app, and clicks it
• Scrolls down to the example section, and clicks on one of them
• Looks at it for a bit
• Navigates backward

This puts them back to where they were in the browser before navigation to app.rerun.io. That's quite a jarring experience.

The back button in the scenario above should've taken the user to the welcome screen, with the scroll position restored from before they opened the example. They may then either:

1. Open a different example.
2. Navigate forward to go back to the example they opened previously.

We should implement a navigation history within the viewer, mirroring the web history API. What exactly requires an entry in the navigation history is somewhat unclear. We can start with only keeping track of navigations between the welcome screen and a recording, and between individual recordings when multiple are open at the same time.

We may eventually want to expand what we keep track of in the navigation history to more than just the welcome screen and recordings. For example, in Slack, clicking on "replies" under a post thread will "split" the main content area into the channel and reply thread (as long as there is enough space for both), where navigating back will close the thread, and subsequently navigating forward will re-open the thread.

[nikolausWest]

For the simple case here, would we drop the recording if you click and example on the welcome page, wait for recording to load, press back?

[jprochazk]

As a first step, we should handle only navigations between the example page and recordings:

• Opening a recording from the example page set a "navigated from example page" flag.
• Pressing the back button when the "navigated from example page" flag is set will close all open recordings, effectively returning the user back to the example page.
• Pressing the back button when the "navigated from example page" flag is not set will fall back to the browser default behavior, and on native do nothing.

This may introduce weird edge cases, but we're okay with that, because we just want the happy path of onboarding to work.

[nikolausWest]

This is "high" urgency if it's a quick fix. Otherwise it's "medium"

[emilk]

Sounds like a good plan

[emilk]

We can also use the strategy of egui.rs and add #fragments to the url which is a real part of the history

[emilk]

It seems like the best course of action would be to use the history API, as Jan suggested.

When leaving the examples/welcome page (clicking an example) we can call both:

history.pushState({}, "", "?examples");
history.pushState({}, "", "?url=…");

Then when the user hits the back-button, they will end up at ?examples (which we would need to parse and handle). When they press the forward button again, they end up at url=… which will load the example again.

We would need to install an even handler to listen for these changes with

window.addEventListener('popstate', function(event) {
   …
})