1225350 - service worker fails to start in offline mode for fresh tab in e10s mode

Status: RESOLVED WORKSFORME

(Core :: DOM: Service Workers, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

Steps:

1) git clone https://github.com/wanderview/wanderview.github.com.git
2) git checkout source
3) rake preview
4) Navigate to localhost:4000
5) Click the first blogpost link
6) Click the home icon to go back to the index
7) Kill rake preview
8) Manually entry localhost:4000/index.html in the URL bar
9) You should see an offline error page provided by the site.
10) Close the browser
11) Reopen the browser
12) Attempt to open localhost:4000/index.html

Expected:

The same offline error page is shown.

Actual:

The tab spins forever.  If you manually enter other pages that were cached into other tabs, then you get "server cannot be reached".

It seems the service worker is being removed somehow.  In stderr I see this:

[Child 20994] WARNING: 'NS_FAILED(aStatus)', file /Users/bkelly/devel/hg/mozilla-central/dom/workers/ServiceWorkerScriptCache.cpp, line 707
[Child 20994] WARNING: 'NS_FAILED(aStatus)', file /Users/bkelly/devel/hg/mozilla-central/dom/workers/ServiceWorkerScriptCache.cpp, line 315
[Child 20994] WARNING: 'NS_FAILED(aStatus)', file /Users/bkelly/devel/hg/mozilla-central/dom/workers/ServiceWorkerScriptCache.cpp, line 485
[Child 20994] WARNING: 'NS_FAILED(aStatus)', file /Users/bkelly/devel/hg/mozilla-central/dom/workers/ServiceWorkerManager.cpp, line 959
[Child 20994] WARNING: 'NS_FAILED(aStatus)', file /Users/bkelly/devel/hg/mozilla-central/dom/workers/ServiceWorkerManager.cpp, line 315
[Child 20994] WARNING: ServiceWorkerJob failed with error: NS_ERROR_CONNECTION_REFUSED: file /Users/bkelly/devel/hg/mozilla-central/dom/workers/ServiceWorkerManager.cpp, line 321

This only happens in e10s mode.  I suspect this is related to the PropagateSoftUpdate() code.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Andrea, do you have any ideas here?  Since it only happens in e10s mode I suspect its related to the soft update propagation somehow.  Also, see bug 1225121 for another case where the propagation is getting us into trouble.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Note, I can't provoke this with my real site https://blog.wanderview.com.  I think this is because the cache headers are set such that we're not triggering an update.  The local rake version essentially sets the resources with no max-age.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

There is a good chance this is related to the same failures we see in bug 1186856.  If the new SW fails, we don't restore the old registration.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

Comment 3 was wrong.  This site uses skipWaiting(), though, so this could be due to the missing activation queue.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

We should retest this.  I'm fairly certain this was due to an update firing during navigation and the skipWaiting() doing something bad.  In 45+ we now update after the navigation completes which avoids this problem.  The one user I saw with this problem in the wild reported it was fixed in 45+.

We also had various update propagation problems in e10s mode which have been fixed.

I have a separate bug in my queue to fix issues with skipWaiting().

Comment 6

[Jim Mathies [:jimm]]

bkelly, does this block e10s? if not, what kind of priority would you put on it post rollout?

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

I haven't seen this in a while or heard of any bug reports to this effect.  I'm marking WFM given changes mentioned in comment 5.