Dom / Sweet - this might be what gmail were talking about last night?
Mike - I think you had noticed this with gmail

Confirmed on Linux via chrome://serviceworker-internals that the photos.google.com's SW gets unregistered when reloading while offline. Don't know what's triggering it.

Doesn't this break offline? If so why is it only P2?

Could this be a bug in the Dev Tools service worker panel? 

For Gmail, chrome://serviceworker-internals seems to show the service worker is still running. It looks like the issue goes away, if you opt-in to Offline mode on the specific device (the opt-in is tied to the device), disconnect from the network, and then reload the page.

Photos doesn't have a fetch handler, and Wahbeh (cc-ed) noticed that DevTools doesn't show the service worker at all, if fetches are not being handled offline.

Adding couple folks from Gmail and Photos teams, to see if they can help with debugging this issue.

c#3: Fair question:
- It happens in 68 Stable, therefore it's not a regression in 71, therefore is not needed for this milestone, therefore P2.
- It appears to be limited to these Google sites only, so likely something the sites are doing.
- My hunch is it doesn't "break offline". I think Mail and Photos use service workers for notifications and not for offline. I had to click "enable notifications" to get a Mail service worker. I don't have Photos one.

I welcome further evidence to help us prioritize this.

Makes sense, thanks for the explanation!

#4 It doesn't seem to be limited to dev tools. I've tested without dev tools, just loading the site (checking it has a SW in dev tools), then putting laptop into airplane mode, refreshing (error screen), and checking no SW in dev tools.

#5
> My hunch is it doesn't "break offline". I think Mail and Photos use service workers for
> notifications and not for offline. I had to click "enable notifications" to get a Mail
> service worker. I don't have Photos one.

Aha! I just saw https://www.reddit.com/r/chromeos/comments/9almml/psa_gmail_offline_is_now_available_in_the_new/). Go to Settings. There is an Offline tab which has a checkbox you can enable.

After waiting for it to sync, now I go into airplane mode and refresh and ... it works!

So I think it *is* something Gmail is doing deliberately, when offline mode is not enabled, but when offline mode *is* enabled it works offline.

But why? Why delete the SW when offline if offline mode is disabled? Why not show a proper error page ("next time you're online, you might want to enable Offline Mode"), instead of just deleting the SW?

(Replying with my personal email because at home.)

I was chatting with landry@ about Gmail and service workers. Gmail is a little complicated when it comes to service workers because the scope of the worker depends on whether you're using multi-login (e.g. /mail, /mail/u/0, /mail/u/1, etc). There's a fairly complicated series of 301 redirects right now that bounces users to the right place, and perhaps this is what is getting triggered when you hit this bug?

In chatting with landry@ I think we determined that introducing a top level service worker at mail.google.com in place of the 301s to handle the delegation down to the right sub service worker was the right approach but this will take a bit of work on Gmail's part. 

I've tried to repro for Photos and can't repro, here's how I am trying, let me know if I'm missing something:

Chrome 68 - Mac
- open photos.google.com
- check devtools and chrome://serviceworker-internals/ to see a SW
- turn wifi off, refresh the page
- chrome://serviceworker-internals/ does show a SW
- devtools does not directly because we are now on a dummy page so you have to click "service workers in other domain"

Comment#8 mention multi login. As far as I know the Gmail and Photos SW do not share code but we do share the multi login infrastructure so maybe it's related to that. Can someone repro the original issue and mention if they are using multi login?

I think #9 is right. The SW isn't getting deleted, it just isn't visible at the top of dev tools because it isn't considered a match for this domain.

I tried Photos again. Even though the domain is still "https://photos.google.com" on the Omnibox, I think that's "fake", because document.location.href gives "chrome-error://chromewebdata/". Also the Omnibox shows "Your connection to this site is not secure", which is weird, because it's served from an internal Chrome page.

So I think what's "really" happening is:

1. Photos and Gmail (in the latter case, when Offline mode isn't being used) have registered a Service Worker, but aren't serving anything when offline.
2. When no response comes from the network or SW, Chrome displays the page "chrome-error://chromewebdata/" (with a fake Omnibox still showing the requested URL).
3. Dev tools shows the service workers for the chrome-error://chromewebdata origin i.e., none since that origin doesn't register a SW. You can still see the https://photos.google.com service worker in "other origins", but not at the top.

I think this is what #4 was trying to tell me but I didn't understand :)

So no real bug here, just some sites that aren't working offline. However, it would be best if dev tools showed the SW for the "fake" domain at the top, which is still the SW directly responsible for the current page, even if theoretically we're showing an error page from a different origin. Renaming and assigning to dev tools.

Hm, that's an existing bug tracked at issue 864880.

I thought this was different because I saw in chrome://serviceworker-internals the registration was unregistered.

Ah. Well, I'm seeing them registered still in serviceworker-internals, also confirmed in #4 and #9. Seems like it's just you (in #2) that says it's being unregistered in serviceworker-internals.

If that's true, then this is a legitimate different bug. Otherwise, it's a dupe of Issue 864880.

Renaming this back to the old title in case this is a separate bug, but I don't think anyone else here has reproduced it.

I see now. My serviceworker-internals indeed shows the registration still exists. The trap was it also has an entry like this:

Unregistered worker:
Installation Status: REDUNDANT
Running Status: STARTING
Fetch handler existence: UNKNOWN
Script: https://photos.google.com/serviceworker.js

I think this is the worker created for the update check when the page was reloaded. I'm not sure why it's installation status is REDUNDANT and running status is STARTING. In any event, we'll fix spawning workers for the update check in issue 648295, so this zombie worker should go away.

Therefore, I'll dupe this to issue 864880.