Thanks for filings these, I'll look into them. Few questions below:

- How do developers know about these? I'm seeing multiple conflicting requirements on the web. Any canonical documentation available that I can use to make my app installable?

- 'SW doesn't have a fetch handler' is interesting - I can see some canonical examples registering dummy listeners to work around it. Is that going to change?

- I'll drop the HTTPS and 'The app is already installed' ones because those are either redundant or not actionable. All I care is that it is installable.

- the start_url isn't within the scope of the manifest

Could you also elaborate on this one and point to where it is implemented?

> How do developers know about these? I'm seeing multiple conflicting requirements
> on the web. Any canonical documentation available that I can use to make my app
> installable?

Our documentation on this is at:
https://developers.google.com/web/progressive-web-apps/checklist

It's deliberately (for better or worse) non-exhaustive. We tell developers to run their site through Lighthouse and if the Lighthouse approves, then it's a PWA. If not, it might still pass the Chrome check, but we reserve the right to increase those checks. (Essentially, Lighthouse is the "gold standard", while Chrome implements a subset of that check.)

Thus, arguably, we don't need this check in dev tools, because we have Lighthouse to provide a stronger set of checks. I think the reason we wanted a feature in dev tools that shows you EXACTLY what Chrome is going to do is so developers have a "final sanity check" to make sure it will install in Chrome. Thus, if we're going to have this feature in dev tools (separate to Lighthouse), we need it to exactly match Chrome's check.

> 'SW doesn't have a fetch handler' is interesting - I can see some canonical
> examples registering dummy listeners to work around it. Is that going to
> change?

We plan to change this, yes. Sites that register a dummy fetch handler should not be considered installable, it's just very hard to precisely define what it means to have a non-dummy fetch handler. We plan to add new logic to Chrome's installability check and when we do that, we'd expect dev tools to match the new rules.

> I'll drop the HTTPS and 'The app is already installed' ones because those are
> either redundant or not actionable. All I care is that it is installable.

I agree about "the app is already installed" (we want to show developers the *static* properties of their site that would make it installable or not, not take into account the user's state). Why is HTTPS redundant? Do you mean if we made a SW check then HTTPS would be redundant?

> the start_url isn't within the scope of the manifest

This isn't really part of the installability check; rather we update the manifest scope to match the start_url if it isn't already within scope. I'm not sure if there are any errors that would need to surface here.

Note: Marking as a regression since before M-73 this wasn't misleading developers; now it is potentially confusing.

>> Marking as a regression since before M-73 this wasn't misleading developers; now it is potentially confusing.

Not sure how this is a regression, given that action used to do nothing and now it performs at least some validation with no false positives.

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

commit 2bf92815fc1b1a557cd4c3280396d375e9121f5e
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Tue Dec 18 03:39:58 2018

DevTools: require that the SW is present when assessing installability.

Bug:  915943 
Change-Id: I39e50986d1331a90444d68ce3328a9bf8c530073
Reviewed-on: https://chromium-review.googlesource.com/c/1380675
Commit-Queue: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617368}
[modify] https://crrev.com/2bf92815fc1b1a557cd4c3280396d375e9121f5e/third_party/blink/renderer/devtools/front_end/resources/AppManifestView.js
[modify] https://crrev.com/2bf92815fc1b1a557cd4c3280396d375e9121f5e/third_party/blink/renderer/devtools/front_end/resources/ApplicationCacheModel.js
[modify] https://crrev.com/2bf92815fc1b1a557cd4c3280396d375e9121f5e/third_party/blink/renderer/devtools/front_end/sdk/ResourceTreeModel.js
[modify] https://crrev.com/2bf92815fc1b1a557cd4c3280396d375e9121f5e/third_party/blink/renderer/devtools/front_end/sdk/ServiceWorkerManager.js

Bug reporters, don't be alarmed, I'm still up for C++ unification. I'd like to outline the UX for now - it is trivial to do on the front-end side.

To recap, this is the status of the checks. Note that there will be a backend-based follow up, but status below is here for the record:

[+] the site has no service worker
[+] there is a service worker, but the service worker doesn't have a fetch handler
[+] the start_url isn't within the scope of the service worker
[+] the document URL isn't within the scope of the service worker
[+] the icons in the manifest can't actually be fetched or decoded properly


[-] the start_url isn't within the scope of the manifest
  is not a part of installability check as per #4
[-] site isn't served over HTTPS
  secure origin is a subset of the SW check
[-] the app is already installed
  is not relevant for the DT-based check.

With those, I think it is fine to close this while leaving https://bugs.chromium.org/p/chromium/issues/detail?id=915945 open.

Please reopen the bug or let me know if there is still something missing.

As per comment #0, Tried testing this issue on Windows 10 on the mentioned chrome version 73.0.3639.1 by following the below steps.

0. Launched chrome 
1. visited keep.google.com
2. Opened DevTools
3. Clicked on the Application tab
As we have not seen warning in devtools
Attached is the screen cast for reference.

Pavel Feldman@ Request you to check and confirm if anything is missed from our end in verifying the issue and help us to verify the fix.

Thanks..!

Deleted: 915943.mp4 1.0 MB

	915943.mp4 1.0 MB View Download