Don't navigate existing clients by default

[alancutter]

Extracted from TAG review: https://github.com/w3ctag/design-reviews/issues/683 @LeaVerou @kenchris @hober

https://github.com/w3ctag/design-reviews/issues/683#issuecomment-988134711

When a client is being navigated, will this mean that a new entry is added to the session history so that you can get back to earlier state? (like right click on titlebar and click 'back')

Yes, it's treated like a regular navigation and navigation history is retained as usual.

https://github.com/w3ctag/design-reviews/issues/683#issuecomment-988134711

Bigger picture, one of our concerns is that this facilitates user hostile behavior, where new content entirely replaces old content and the user loses their current state.

For example, consider the native Google Maps application. Clicking a maps link from anywhere else replaces your current state with no means to retrieve it or toggle between the two (e.g. to compare routes). Even in the music player example, does the user desire for their state to be entirely replaced, or merely for the previous song to be paused?

We understand that it is possible to maintain the previous state with custom coding, but we are concerned that the easiest, most straightforward thing to do is what most native apps do, which is to entirely replace user state. We'd love it the Web could do better.

What are your thoughts about how to address this?

This is an interesting juxtapose to my concern in the opposite direction: https://github.com/WICG/sw-launch/issues/43

I'm not sure "user hostile" is the best term to use here as I don't think the site benefits from either of these scenarios and they would only arise accidentally due to a lack of JS resulting in the default behaviour (whether navigating or doing nothing) being undesirable for the situation.

Either default can be bad if the app doesn't intercept it when necessary.

• Default navigate: User loses page state (though not always with Chromium's bfcache).
• Default retain: User is unable to navigate to specific app links without going back and copying the URL into a browser at which point they're no longer using the intended web app experience.

I think either sites should be able to choose which default is most appropriate for their app or the default should be to navigate to avoid web apps accidentally breaking their own link navigations if they do nothing (suggested here).

[mgiuca]

It's a tricky dilemma. I'm also uneasy about navigate_existing_client, but if developers are going to do it anyway then why make it harder for them?

As I understand it, if we didn't provide navigate_existing_client, developers could implement the exact same behaviour by having a launch handler that immediately redirects the page to the new URL. navigate_existing_client is just a shortcut for developers.

The framework I would use to think about this is, which is true:

• a) this shortcut will make developers lazy and perform sub-optimal behaviour (i.e. devs could implement generally better logic if they wrote a custom launch event, but because that's hard, they'll just do the sub-optimal but easy thing), or
• b) without the shortcut, developers will still just implement the same logic with launch event anyway (therefore we may as well give them the more convenient API to do so).

Assuming that we're going to give developers the ability to navigate an existing client, the question is, is the API for doing it the "quick and dirty way" a footgun, or a legitimate shortcut for perfectly reasonable behaviour.

[evanstade]

There will be footguns either way, as Alan points out in #43. Which footgun is worse? My opinion that doing nothing is a worse footgun than clobbering state (state which is often still accessible via the back button). To argue that navigate_existing_client: always is a bad default because it clobbers state seems to imply that <a href> also has a bad default because it clobbers state (non-default target="_blank" introducing the state-saving behavior).

My feeling is that native mobile apps like Spotify and Google Maps clobber state when handling links because mobile OSes make it hard to create apps that facilitate user multitasking. The hurdle is not writing a couple lines of code but creating an in-app interface to switch between different user tasks. Authors of a mobile mapping app would do the right thing by not clobbering state if it were easy/possible to have two instances of the app open at once. Mobile browsers are a good example where app authors did put in the work to create a way for users to multitask, i.e. tabs. And because this exists, mobile browsers choose to open a new tab when handling a link, thus preserving state. Since the web platform makes it relatively easy for apps to preserve state (i.e. by using new windows or tabs), they will.

Since I was asked for the File Handling perspective, let's imagine a few File Handling apps.

• The canonical type of File Handling app is probably an editor (of text, or perhaps images, spreadsheets, or other things). In this case, they probably don't want to clobber state, e.g. a half-written homework assignment. So the "safe" default would indeed be do nothing. But that's still a pretty lousy outcome, because what the user actually wants is to open both documents at the same time. Having nothing happen when the user double clicks a file in the file browser would feel very broken and mysterious. And having launches do nothing by default does nothing to protect against data lost by other means, such as accidentally closing the app window. So launch_handler aside, an editor app ought to both auto-save and also have an onBeforeUnload prompt to prevent data loss, in which case the navigate_existing_client: always default wouldn't cause data loss.
• Another potential file handling app would be a file converter such as mconverter. In this case I think clobbering state is perfectly fine since the user flow is generally "open file => save as different type" i.e. there's very little state to be clobbered and instead doing nothing just feels incredibly broken.
• A local music player app (if those still exist). What did WinAmp do? IIRC what would have happened (what the authors of that native app chose, when they could choose anything) was that a new track would have been enqueued in the open playlist, not that a totally new player would have been opened. No default is good here. Doing nothing would feel broken; clobbering the playlist would be infuriating. Since it's a pretty core user journey I think the authors would make sure it behaves correctly (enqueues) and not succumb to the temptation to go with whatever's easiest.

[alancutter]

I want to signal boost the part where onbeforeunload is respected by navigate_existing_client: always. Sites with significant page state already use this event handler to prevent accidental data lossy navigations.

[alancutter]

Sorry I just realised this issue is made obsolete by just not having a default value: https://github.com/WICG/sw-launch/pull/53