Are your proposed solutions to the problem a) things that should change in the spec, b) things that Chrome should do, or c) things that the site should do. I'm not exactly clear where you are proposing these things take place.

I think the proper solution to this problem lies in the manifest's "serviceworker" member:
https://www.w3.org/TR/appmanifest/#serviceworker-member

I'm not sure what our implementation status of this is (does Chrome automatically register SWs based on the manifest)? According to the spec, it "can" (I guess this should be "MAY") automatically install the nominated SW:
https://www.w3.org/TR/appmanifest/#dfn-steps-to-install-the-web-application

So the solution is for:

1. Chrome to start automatically installing SWs mentioned in the manifest.
2. The example site to mention the top-level scoped SW in its manifest "serviceworker" member.

Thus, when the user navigates directly to https://blah.example.com/sub/folder, that page points to the manifest which has scope "/" and also nominates a SW with scope "/". We install the SW and then the PWA check sees that there is a SW registered that matches the manifest scope.

For failure case 2, that just seems like Chrome's PWA check is bad. Why is "the start_url is controlled by the same service worker as the user's current URL" a requirement? We shouldn't require anything related to the user's current URL; the PWA check should just be a property of the manifest. I think the only requirement here should be "the start_url is controlled by a service worker."

Thanks Matt. We do require certain properties of the current URL: we require it's served over HTTPS for instance (and that's necessary for installing a service worker). We don't load the start_url, so checking that the current page is HTTPS and that the start_url is controlled by the same service worker acts a little like a proxy check that the start_url is also secure if we didn't load it. It's kind of roundabout.

As an aside, maybe we should have at least an explicit scheme check for the start_url (I'm not sure we even do that right now).

I don't think we handle the manifest service worker member right now. There are a few footguns here with racing the manifest service worker and the page's service worker (possibly resolvable using the skipWaiting method in the worker that's supposed to win). But otherwise that may work. 

Spoke to falken@. He pointed out (obviously in hindsight)... why doesn't the page itself just register the "/"-scoped SW along with the "/sub/folder"-scoped SW? Then no need for the manifest registration. That should solve problem 1.

Problem 2, I just think we need to rework the check. I guess if the current document isn't on HTTPS, then I suppose that doesn't invalidate the manifest's PWA necessarily, but it also means the current page shouldn't offer to install (since the current page isn't *inside* a valid PWA). So I'm happy to keep that check.

For the start_url check, though, I don't see why we have to load the start_url in order to check that it's scoped inside a SW. It's just a string operation on the URL string.

Yep, registering both service workers was something suggested in the first post. It incurs a cost to the page - extraneous JavaScript - and generally feels like something we could address in a more elegant way.

I think if you're going to design a site with two nested service workers, then you have to pay the cost of setting both of those up. If you only want one SW, make it the top-level one.

So it looks like we can make this work if we want, as long as sites code for it. So, do we want it?

From Dom's first post: "Addressing problem 2 means we need to relax the requirement that the current page and the start URL are controlled by the same service worker."

Personally I am all for this. I think the SWs are an implementation detail and it isn't important how many there are. They don't need to align with app boundaries. Put another way, they are like DLLs. Some DLLs might be just for one app, some might be shared services.

That's my vote but I'm interested in other folks' thoughts, especially Alex and Matt.

Dom, you said 'feels like something we could address in a more elegant way'. Do you have anything concrete?

As discussed above, I think Problem 1 is a site problem. The /sub/folder page is bad because it doesn't register the "/" SW (in general, every page inside a SW scope should register the SW).

Problem 2 I think we should fix by relaxing the requirement. I can't think of a reason not to do that.

Any more thoughts about this? Bumping priority as this will be a blocker for some very important sites.

Does relaxing the requirement ("a PWA's manifest must be scoped inside the document's active SW" → "a PWA's manifest must be scoped inside some registered SW") fix the issue?

I think you mentioned that there might be other problems, but I don't see why that would be.

I think that fixes it.

The challenges would be writing code that checks this successfully. Currently there is some complexity to make sure the check is done once the SW is installed, now we'd potentially need to wait for multiple SWs to install.

#10 there is? I thought we execute the check potentially before the SW is installed, which is why sometimes I don't see "Install" in the menu and then if I open it again seconds later, it's there.

Where do we actually hard-block on waiting for the SW to be installed? (If so, I agree this is a problem, as we'd have to wait for potentially any number of SWs to be installed.)

As discussed this is during the flow to work out if something is installed, not in the installation flow itself.

Dom - any advice on this?

(Sorry for the delay)

We hard-block on SW installation when working out if we should fire beforeinstallpromptevent. If the user manually adds, we do not wait, we simply check existing registrations/active SWs.