Single-window mode option

[mgiuca]

We're looking into installable apps on Desktop platforms (in Chrome) and have identified two different types of app (at least):

• Multi-window: Feels like the default since it's closest to the web model. Links to the app create a new app window. Launching the app opens a new window.
• Single-window: Only ever has a single instance. Links to the app perhaps just focus and navigate the existing app window. Launching the app focuses the existing window.

On Mobile, we effectively have the single-window version (that mirrors how native apps tend to work on Mobile). But on Desktop, it seems that multi-window should be the default, but apps may still wish to opt in to single window.

How do we feel about adding a Boolean property in the manifest to force a single instance?

This is just a discussion point. We are considering alternatives to this (which I will post here soon).

[kenchris]

I am wondering whether we could handle this in the Service Worker instead (maybe some default code in workbox)?

In a service worker you can find existing open windows and focus then, or just open a new window.

(see https://gist.github.com/kenchris/0acec2790cd38dfdff0a7197ff00d1de which is some research on how to support shortcuts)

[yfriedman]

I think that may be over-simplifying the view of mobile a little bit (and tablets can have similar issues). It's true that a user may typically only see one window at a time, but under the hood (and it affects things like task management, back-stack and more) this is actually done by re-using an activity or launching a new instance. If you haven't seen it, the docs on launch modes for activities on Android may be worth some consideration: https://developer.android.com/guide/components/activities/tasks-and-back-stack.html#TaskLaunchModes

Anyway, the reason I mention all this is that getting this right can be quite challenging - we've certainly faced some difficulty implementing it on Android and are still dealing with some issues related to back-button across activities. Also given that mobile and desktop would have different defaults, how do we rationalize this?

[mgiuca]

This proposal is (deliberate) over-simplifying. I made this issue as a "what's the simplest thing we can get away with" type of question. I think we could also go to the other extreme end, or somewhere in the middle.

@kenchris yeah, I've been thinking about this in a service worker context, and relevant to your other proposal too (in fact your other proposal is what started me thinking about this).

My proposal

This covers all three use cases of:

• Single-window mode apps
• Your shortcut API proposal
• Web Share target

What do you think?

[delapuente]

This has been discussed previously here and in the ServiceWorker repository: #479, w3c/ServiceWorker#1028

[annevk]

Note also that the mobile experience can be rather detrimental to the experience for more advanced users. E.g., not being able to open multiple Twitter views.

[mgiuca]

@annevk I agree and I'm quite conscious of building tech that takes away options from power users.

However, this is a feature request we're getting a lot when asking potential customers about desktop PWAs. I think the best solution is to 1. make multi-window the default, 2. let developers override that default if desired, and 3. let users override that override if they want to.

So I'm a fan of Jake's "launch" event proposal, which is basically my suggestion but it doesn't trigger in situations where the user has been explicit about their intent. Essentially, it means a left-click on a link or shortcut behaves as the developer wishes (can collapse into a single window), but a middle-click or right-click-open-in-new-tab on a link bypasses the "launch" event and always opens a new browsing context. Are you OK with this?

[annevk]

Somewhat, it seems rather confusing for users as they won't know the default that a domain uses so they might end up replacing views they didn't mean to. I guess the answer is that they'll always have to ctrl+click or flip a preference to make that the default...

[mgiuca]

A bit similar to how I never know whether a left-click is going to replace the current tab or open a new one (e.g., clicking a link in an email) so I often end up middle-clicking a lot anyway.

I think we'll want to give developers some guidelines that this should only be used if your app makes no sense in multiple instances, or if you are actually managing instances inside the one view, so either way there should be no data loss if you do this. Examples of where I think it makes sense:

• An IRC app with multiple chat panels inside a browser window. Using this API to suck a navigation into the single app window doesn't lose any data or state, it just opens a new chat panel.
• A music player that only wants a single window so they don't play music over the top of each other. If the user navigates to an album, can navigate to that album's track listing in the single window, while still playing the existing track in the background. User can close the new album track listing to go back to the previous track listing.
• A game where it doesn't make sense to be running multiple instances at the same time. In case you click a link to the game that's already running, we just switch to the current instance. Almost all "real" native games on desktop behave this way.

Ultimately, the user is able to override any of the above 3 cases if they really want to, but the developer has (rightly) decided that an average user shouldn't be exposed to multiple windows because it's more confusing than it is useful.

[annevk]

Your IRC example made me remember that we already offer a similar ability through registerProtocolHandler() although that works a little differently. We should probably look into if we can reconcile that somehow.

[mgiuca]

Doesn't RPH always open a new browsing context? (e.g., I have a Gmail tab open already but if I click a mailto link, it opens a new Gmail tab, at least in Chrome.)

If anything, RPH gives us another example of a case that benefits from my above proposal (like Web Share Target); Gmail can open a new compose box in the existing tab instead of opening a new one.

[annevk]

Yeah, that's what I meant with reconcile. Might actually work as-is, but RPH isn't defined very well.

[delapuente]

A very similar discussion happens in bug w3c/ServiceWorker#1028 also. Perhaps we could move the conversation there.

[mgiuca]

Yes. I'll keep this issue open (since that one is in a different spec), so we have a tracking issue for the high-level concept of single-window mode in the manifest. We can discuss on the SW event.

[mgiuca]

Note: this would also be closed by my declarative link capturing proposal, which is simpler than the launch event mentioned above (with an option to upgrade to it later). See #764 .

[kenchris]

What is the latest on this @mgiuca ? declarative link capturing got deprecated

[mgiuca]

Yes, DLC is deprecated. Its replacement, Launch Handler API is shipped in Chromium browsers, but at the spec level it's still in incubation stage.

Eventually it could go in Manifest if it had cross-engine support. For now, I think we should leave this open as it is not implemented in the Manifest spec.

(Specifically, the Single-window mode is implemented by using the focus-existing option.)