Additional property to define a webapp to be single instance (single-tab)

[leolux]

Might the manifest be a possible solution for the following issue?
http://stackoverflow.com/questions/38274915/how-to-launch-webapps-as-a-single-tab-single-instance-app

[marcoscaceres]

I think that is covered by the "scope" member to a degree: a user launching an app would open at the start URL, but subsequent (re)launches of the app, if the app is already open, could simply refocus the tab and not navigate.

We should probably clarify that in the spec.

[leolux]

That would be great! Thanks!

[benfrancis]

I don't think this behaviour should necessarily be part of the spec.

While one window per app is common on mobile, that's not so much the case on desktop. Also, being able to have the same website/app open in multiple tabs is arguably a feature the web has which many native app platforms do not.

Perhaps the user wants two instances of the app open to do a side-by-side comparison. I'm curious about the underlying motivations for this - really web pages should be designed with the assumption that they can be opened in multiple tabs at the same time as this is usually the case in the browser.

[leolux]

I disagree with your conclusion that there is no need for a signle tab feature.

As you say there is no need to specify a multiple tabs feature for web apps because this behaviour is the only one which exists today. For the most apps this is just fine because they just don't care about how many tabs the user has opened. Some apps even make use of multiple tabs. But there is really no argument to say that all web apps of the future should be designed this way.

Instead I would like to argue why a single tab feature is needed and required to be supported by the spec from my perspective:

1. There is no single tab feature today which makes this feature needed in the first place
2. I have a real business case for an realtime web app which is intended to be used on mobile phones only and for a timeframe of 3 minutes (timeout of the app). Users can relaunch this app during the execution of the app for the purpose of reconnection and they can launch the app after the timeout again. Anyway this app should exist only in one tab. (You can ask questions about this app but details of the business case have stay secret)
3. The single tab feature might also prevent resource wasting which is commonly known to be best practice on mobile phones

[benfrancis]

How will you make your web app backwards-compatible with web browsers which do allow users to open it in multiple tabs simultaneously?

I'd suggest you might want to reconsider the design of your app rather than the design of browsers.

[leolux]

Yes, that's a fact. My web app supports multiple tabs because the design of browsers forces me to.

The argument of backwards-compatibility is only a matter of time. Many APIs are adopted by major browsers in a short period of time. Compatibilty is the worst argument against the single tab feature because existing features are not touched. Instead the new feature is only an additional feature.

[benfredwells]

Can you solve this issue already with service workers? That is, keep track of open windows in your service worker, and send new navigations into open windows, if any exist?

[marcoscaceres]

Can you solve this issue already with service workers?

Maybe, I don't know how to intervene in a navigation with SW.

That is, keep track of open windows in your service worker, and send new navigations into open windows, if any exist?

I get how one could check the focused clients through the SW, but never seen intervention of navigation. Would love to see some code, even if a rough sketch.

[marcoscaceres]

As an aside, I tend to agree with @benfrancis that this is complicated given browser behavior (I don't see that changing - though behavior that matches launching native apps from the home screen is obviously something we want too). So if we can solve it with SWs, then that would great.

[benfredwells]

After doing some reading I think this isn't possible currently with SWs, but the pieces are almost there:

• SWs can intervene in network fetching via the fetch event, but not with navigation itself
• SWs can use Clients.openWindow to open existing windows, however that is currently only allowed in response to a notification click event.

[delapuente]

I think service workers are more suitable to do this. Perhaps not with the fetch event but with navigation. Let's open an issue there...

[duanyao]

Native applications usually use file lock or named pipe to achieve this purpuse, so I think the web need similar mechanism. In one of my project, we use storage event of localStorage to implement a poor man's lock mechanism.

Some previous discussion:

https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0151.html
https://lists.w3.org/Archives/Public/public-whatwg-archive/2009Sep/0267.html
https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191

[marcoscaceres]

@delapuente, can you check the link to the SW issue? It seems to point back here.

[leolux]

Github automatically generated a link to the issue "Consider providing navigation event #1028"
which is w3c/ServiceWorker#1028

[aarongustafson]

Duplicates #597 (and discussion has moved there).