Ping - haraken@, can you comment on whether it's possible to check if a PWA is available offline?

falken and nhiroki should be more familiar with SW.

Some better heuristic is of course possible. Some options include:

- Check Cache Storage to see if start_url is cached (there will be some false positives and false negatives: even if cached the SW might not serve it; the SW can serve something that's not cached; and even if cached and served it might not be the full page)
- Somehow disable network including network cache (not sure how easy that is) and simulate a request for start_url. See if the SW comes back with a response (but same caveat as above, it might not be the full page).

Checking the cache for start_url is more likely to result in false negatives I think. Eg, anything that uses a page shell will be missed.

Is we implement cache modes, could we perform a head request foe the start url using a "only from cache" cache mode? That way it's likely to fail if it's passed directly to fetch().

That will show positive if the site serves a response, even if it's a fallback page.

+tyoshino if he has ideas about using the cache mode for this.

Any further ideas on this? benwells@ and I are currently not convinced that there is a reliable and practical option amongst those presented so far. If we can't settle on something, I'm comfortable saying that it's not practical to make this check.

Just adding to what Dom said, this is something we'd be doing to figure out whether to show the banner or not. As a result we might end up doing it fairly often, as pages are loading / users are otherwise interacting with a site.

benwells@ and I had a discussikn with falken@. There will soon be a way to query whether a service worker has a fetch event attached to it. However, properly testing that a URL works offline by shutting off the network and making a request is very heavyweight given the currently architecture. It's also prone to decisions made by developers in what/when their service workers provide when offline.

Another potential option is to cultivate and query some sort of cloud database of apps which work offline. We're not too sure of the feasibility of that - owencm@, do you have an opinion on this option?

The method referred to in comment #8 is now available as ServiceWorkerVersion::fetch_handler_existence(). Over to piotrs@ who will be implementing this in the InstallableManager.

The idea is to change existing ServiceWorkerContext::CheckHasServiceWorker method to something expressing the intent of checking offline capability of a service worker. This would allow us to extend it in the future more easily if we find good ways to do so.

ServiceWorkerContext::CheckServiceWorkerOfflineCapability would return an enum with initial states:
1) NO_SERVICE_WORKER
2) SERVICE_WORKER_NO_FETCH_HANDLER
3) SERVICE_WORKER_WITH_FETCH_HANDLER

Returning an enum instead of bool value will allow us more detailed error reporting/logging for the end user.

@falken - any thoughts on this proposal?

Changing to an enum sgtm.

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

commit 3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6
Author: piotrs <piotrs@chromium.org>
Date: Wed Mar 22 06:38:35 2017

Adds a basic offline check to InstallableManager.

Adds a check for existence of a fetch handler in the service worker as a small
step towards checking offline capabilities for the A2HS feature.

Modifies CheckHasServiceWorker method to return an enum distinguishing a
service worker with and without a registered fetch handler.

BUG=601337

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

[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/browser/installable/installable_logging.cc
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/browser/installable/installable_logging.h
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/browser/installable/installable_manager.cc
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/browser/installable/installable_manager.h
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/browser/installable/installable_manager_browsertest.cc
[add] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/test/data/banners/no_sw_fetch_handler_test_page.html
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/test/data/banners/service_worker.js
[add] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/chrome/test/data/banners/service_worker_no_fetch_handler.js
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/content/browser/service_worker/service_worker_context_core.cc
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/content/browser/service_worker/service_worker_context_wrapper.cc
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/content/browser/service_worker/service_worker_context_wrapper.h
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/content/public/browser/service_worker_context.h
[modify] https://crrev.com/3e32ed5683dd6e1cf0178e07c6e58b0e8198a7c6/tools/metrics/histograms/histograms.xml

Fetch handler patch landed, but let's keep this bug for further enhancements for offline checking. There are some things being discussed, but nothing we can easily implement. Suggestions welcome.

Unassigning this bug for now.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot