openWindow with a WebApp manifests

[aykevl]

When using a web application manifest together with a service worker, this can happen:

1. The user opens a web application and installs it as application (using the manifest), for example in Chrome for Android's "Add to Homescreen".
2. The user uses the app as if it were a native application, for example when using "display"="standalone" in the application manifest.

3. The application gets a push notification. When clicking the notification, this code is executed (from MDN:

   self.addEventListener('notificationclick', function(event) {
    console.log('On notification click: ', event.notification.tag);
    event.notification.close();
   
    // This looks to see if the current is already open and
    // focuses if it is
    event.waitUntil(clients.matchAll({
      type: "window"
    }).then(function(clientList) {
      for (var i = 0; i < clientList.length; i++) {
        var client = clientList[i];
        if (client.url == '/' && 'focus' in client)
          return client.focus();
      }
      if (clients.openWindow)
        return clients.openWindow('/');
    }));
   });

4. If only the web application is open, that is opened. If there is no client, a new tab/window will be opened in the browser, not the application saved to the homescreen as expected.

Maybe this is an implementation issue, but I think there should be a way for a service worker to specify how the window should be opened, or it should always be opened as an app if it is installed.

(Note: I never commented on a spec before, so keep that in mind if this issue should be directed elsewhere).

[wanderview]

It seems to me the UA should persist the "saved-to-homescreen" and "display=standalone" bit when the SW is registered. It can then use this information to do the right thing for openWindow().

Of course, this begs the question what should be done if the same site is opened as an installed app and in a normal browser window. Do you end up with two registrations? Are they effectively treated as separate origins? Thats what we do on firefox os, but its unclear to me if thats correct or desirable.

[benfrancis]

Of course, this begs the question what should be done if the same site is opened as an installed app and in a normal browser window. Do you end up with two registrations? Are they effectively treated as separate origins? Thats what we do on firefox os, but its unclear to me if thats correct or desirable.

FWIW we're moving away from this behaviour. I think this maybe relates to deep linking [1] and scope [2]. My interpretation is that when a web app is installed, it should be registered as handling a URL scope specified by the scope property, then any navigation from an existing window or the creation of a new window at a URL within that navigation scope should have the metadata from the manifest applied. In other words, creating a new window within the navigation scope of an installed app should make the browsing context of that window an application context. This is why I think manifest scope is important as well as Service Worker scope.

This is purely theoretical at this point as to my knowledge nobody has implemented this yet. On Android I can see this potentially mapping onto App Links [3], but I'm not sure whether Google has any intention of implementing this part of the spec in Chrome?

1. http://www.w3.org/TR/appmanifest/#deep-links
2. http://www.w3.org/TR/appmanifest/#navigation-scope
3. https://developer.android.com/preview/features/app-linking.html

[wanderview]

Glad to hear we're moving away from installed pages being different effective origins from when they are viewed in the page.

In regards to using scope, though, I think a fair number of people are concerned about them.

Recently it was described to me that historically we've had origins and URLs as primitives on the web. The scope is effectively a new primitive that relates a collection of URLs.

It seems some people are legitimately worried that the scope primitive has not been fully thought out. Having it introduced in service workers and ripple out to other specs may not be the best way to change the architecture of the web platform.

[aykevl]

Chrome issue: https://code.google.com/p/chromium/issues/detail?id=466652

[jakearchibald]

I think there's opportunity here for some kind of "launch" event in the SW, where it can decide if a new client should be opened, or whether an existing client should be used for the navigation, or maybe a navigation shouldn't happen at all.

This would allow you to create multi-window apps (eg docs) or single window apps.

We should discuss this at the f2f.

[slightlyoff]

We've discussed this in a few other issues, particularly regarding giving sites control about how to handle navigation disposition (e.g. https://github.com/slightlyoff/ServiceWorker/issues/758). Moving to V2.

[delapuente]

I gave a presentation in several meet ups about PWA these days and this was a recurrent question:

Is it possible to open the home screen version of the web application when tapping the notification?

One of the approaches would be to rely on scope as @benfrancis is suggesting. Moreover, there is a question about this in stack overflow that points to this Chromium bug but it seems not to work.

The other is to allow openWindow() to decide how to open the new client.

[dominickng]

@delapuente: I just wanted to follow up on the notifications-not-opening-home-screen-web-app issue. I implemented this feature in Chrome (it landed in Chrome 51), and if it's not working for you I'd love to understand why (and try and fix it).

We currently use a heuristic that the link in the notification to be opened needs to share the longest path of the homescreen shortcut's URL. This is obviously a bit deficient, but working out how to do this properly with scopes and the like is complex. Is the notification opening a link that lives on a different origin/path to the app you added to your homescreen?

[wanderview]

We currently use a heuristic that the link in the notification to be opened needs to share the longest path of the homescreen shortcut's URL. This is obviously a bit deficient, but working out how to do this properly with scopes and the like is complex. Is the notification opening a link that lives on a different origin/path to the app you added to your homescreen?

It seems to me this should be a spec'd thing and not just a browser heuristic.

Maybe we could formalize this behavior in the spec for now. In the future we could add some kind of entry to the manifest or a meta tag to match other URLS.

[dominickng]

@wanderview agreed! I'm still quite new to the spec-related side of browser work, so I've been pretty deficient in this area.

I think the original intention of the scope manifest entry was to handle this sort of functionality, but the way it interacts with the service worker scope and potential conflicts with other installed web apps is tricky to detangle.

[zmandel]

This issue is happening to my PWA. Here is another common scenario similar to the case of push notifications:

• From a desktop browser (chrome in my case) app adds a web notification while in foreground (in my app, it "pins" an item for later easy access). App was launched from homescreen as fullscreen.

• User closes the app. Then clicks the notification. My app will use clients.openWindow, but it will open as a new Chrome tab.

One possible solution is for openWindow to use the window styles/size/position of the window that installed the serviceWorker (all of which chrome currently does when launching in homescreen mode).

The issue goes together with using notification requireInteraction (supported in Chrome and planned for mozilla52.) When using that flag, the notification stays up even when closing the browser, increasing chances of hitting this.

[jakearchibald]

I believe this has been fixed in Chrome. If not, please file at crbug.com with recreation steps.