+Dominick, Mounir

What's the motivation for using the longest path in current webapps? I'm not being critical - just trying to get a sense of how you came to it vs say origin. I imagine we're looking for something that's not the single document you're on, but also wanted to support multiple apps on a single origin. Now that we parse the scope member from the manifest, could we switch the default to origin based and require developers to specify scope if they need something more narrow?

In an ideal world, I wonder if the SW registration would actually be the nearest thing to the scope of the app and what you'd want to use?

The longest path was used because you can host multiple PWAs on the same origin. The scope was added to support notification deep-linking - given a link, we wanted to open the webapp which most closely matches the notification link that's being opened.

Additionally, you can add non-SW pages to homescreen that will open in standalone mode and be supported for notification deep-linking (they need to have a manifest and specify display: standalone|fullscreen). I don't think these should be minted into WebAPKs, but it's a separate conversation as to whether they should or shouldn't be allowed to open in standalone if they don't have a SW. Unless we're going to change the current policy, we can't just switch to using the SW registration.

We should definitely use something consistent here.

I would encourage you to have this discussion in the spec's GitHub. Maybe the scope's default value should be something else than unbounded?

#4: Point taken but longest match seems pretty arbitrary, especially in the case where you actually do have a SW registration. Certainly, I would think that SW registration is a better default when present, but agree we'd still need a fallback for when it's not and perhaps that case just wouldn't be relevant for WebApks. Are notifications currently spec'd to default to longest path?

What if we made the decision tree something like:
if scope present in manifest
  default to manifest scope
else if sw present
  default to sw registration
else
  default to longest path

Then we could "unify" the two. I think the origin fallback for webapks is historical but we're moving to a world where SW is required so the fallback case for where it's not is kind of moot..

#5: If there's still pending or spec questions, happy to discuss there, but haven't yet been involved in spec work. I have been perusing the github though and there's open questions on interpretation of scope :)

#6: the decision tree seems fine to me. I'm not sure of the spec for notifications - I should have made it more clear that the current implementation is just an interim until we had the manifest scope member - so I'm quite open to changing it.

Ah, well thanks to Peter, we do have it now: https://codereview.chromium.org/2070433002/

The service worker scope is unfortunately hard to get. We would need to add a new getter to ServiceWorkerContext. Before I start mucking with ServiceWorkerContext, I want to make sure that we want to fall back to the service worker scope if the scope is not specified in the Web Manifest

Falling back to the service worker scope will make the logic to determine whether a WebAPK needs to be updated complicated. The updater would need to check the service worker scope. What should occur if the web developer makes the service worker scope narrower than when the WebAPK was minted? (i.e.  Issue 624236 )

It seems like using the longest path for the scope is an implementation heuristic for finding the right place to route a notification, no? Or does it change the navigation scope too? (And if so, isn't that not to spec per https://www.w3.org/TR/appmanifest/#navigation-scope step 1?)

For WebAPKs the Web Manifest scope affects navigation scope. According to the spec, we should not generate WebAPKs at all if the "scope" attribute is not specified in the Web Manifest. According to the spec an undefined scope means that the scope is unbounded. Unfortunately, very very few Web Manifests on the web include scope.

Currently the Web Manifest scope does not affect TopControlsDelegate#shouldShowTopControls(). I am unsure whether it should

During the WebAPK meeting on Tuesday August 2nd we decided to longest path for WebAPKs too

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/47136bc34e3cc1ce64d23d9c47580283c3102624

commit 47136bc34e3cc1ce64d23d9c47580283c3102624
Author: pkotwicz <pkotwicz@chromium.org>
Date: Sat Aug 06 23:55:39 2016

Make WebAPK use "start URL longest path" as the scope if the scope is missing

This makes WebAPKs and Webapps use the same logic to determine the scope if the
scope is not provided by the Web Manifest

BUG= 624563 

Review-Url: https://codereview.chromium.org/2199413003
Cr-Commit-Position: refs/heads/master@{#410273}

[modify] https://crrev.com/47136bc34e3cc1ce64d23d9c47580283c3102624/chrome/android/java/src/org/chromium/chrome/browser/ShortcutHelper.java
[modify] https://crrev.com/47136bc34e3cc1ce64d23d9c47580283c3102624/chrome/browser/android/shortcut_helper.cc
[modify] https://crrev.com/47136bc34e3cc1ce64d23d9c47580283c3102624/chrome/browser/android/shortcut_helper.h
[modify] https://crrev.com/47136bc34e3cc1ce64d23d9c47580283c3102624/chrome/browser/android/webapk/webapk_installer.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f0d0533acee78764e69b339e64f345e105b5fec1

commit f0d0533acee78764e69b339e64f345e105b5fec1
Author: pkotwicz <pkotwicz@chromium.org>
Date: Sun Aug 07 00:05:27 2016

Remove unused WebApkInstaller::Register()

TBR=dfalcantara
BUG= 624563 

Review-Url: https://codereview.chromium.org/2221753002
Cr-Commit-Position: refs/heads/master@{#410274}

[modify] https://crrev.com/f0d0533acee78764e69b339e64f345e105b5fec1/chrome/browser/android/webapk/webapk_installer.h