1180765 - medium.com connection hangs on subsequent loads

Status: VERIFIED FIXED

(Core :: DOM: Service Workers, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

medium.com seems to serve a service worker. This is the second time I got into a state where medium.com will stay in the "connecting" phase and is just stuck. Opening the same link in a private window loads just fine.

I previously resolved that by going to about:serviceworker and clearing the cached version there but I thought it would be great to investigate what's going on. I'll just leave it as-is and might need some assistance to debug this.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Tim, can you reproduce this with the rev from bug 1178508?  You need to wipe your serviceworker registration for medium.com after updating nightly.

Thanks.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

I might have a script registered before that landed, not sure. I'll clear the cache and reopen if I see it again. Thanks!

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

Here we are again. So what can I do to debug this? :)

Comment 4

[Eric A. Meyer]

Seconding Tim’s offer to help debug this.  I’m getting the same problem, where medium loads fine the first time, and then subsequent visits hang, and unregistering the SW restarts that cycle.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

Tim, Eric, are you guys running in e10s or single process?  What platform?  How often does it trigger?

Obviously we have a race condition somewhere and I'm not triggering it.  Maybe if I make my environment look more like yours I can reproduce it now.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

I think maybe we should also disable service workers on nightly until we can isolate and fix this issue.

Comment 7

[Eric A. Meyer]

I have e10s disabled, and am an OS X 10.8.5.  However, the current build only seems to have this problem in my default setup, which has a number of add-ons.  My testing profile, with no add-ons, does not seem to hang; at least, I haven’t been able to get it to do so in my testing.  Here are my enabled add-ons:

ADB Helper
Advanced Cookie Manager
Autofill Forms
Awesome Screenshot
Bookmark Shortcut Keys
CS Lite Mod
Custom New Tab (currently broken by the new tab behaviors, as it happens)
Disconnect
DOM Blaster
Flashblock
JS Switch
Multirow Bookmarks Toolbar Plus
RSS Icon in Awesombar
Stylish (no styles defined for medium.com)
Terms of Service; Didn't Read
uBlock Origin
Valence
Video DownloadHelper

Tim, any overlap?

Comment 8

[Tim Taubert [:ttaubert] (inactive)]

I run with e10s enabled, OS X 10.10. Add-ons:

AutoAuth	2.1
BugzillaJS	
Customizable Shortcuts
Easy App Tabs
Self-Destructing Cookies

No add-on overlap it seems. Ben, what do we use to store the service workers? If it's a separate file I could probably send it to you?

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

Ehsan says he can reproduce on his mac and will look at it.

I expect this is more of a race condition and my windows machine just doesn't get the timing right (or wrong as the case may be).  The specific file is probably not the problem.

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

Eric, Tim, can you disable dom.serviceWorkers.enabled for the time being and see if that avoids the problem for you?

Comment 11

[Tim Taubert [:ttaubert] (inactive)]

Hmm, this doesn't seem to help?

Comment 12

[Eric A. Meyer]

I've been through several (self-initiated) restarts of Firefox, with SWs both enabled and disabled.  What I've found is that if there is a SW for medium.com present, *even if SWs are disabled*, the hang behavior occurs.  So you have to close all tabs/windows with Medium in them, unregister the SW, _then_ disable SWs, and the problem goes away entirely.  All medium.com URLs load fine for me in that particular state.

I also found that, in situations where the SW was present and thus page loads were hanging, it was usually possible to get the page to load normally with a shift-click on the reload icon.  This was true whether SWs were enabled or disabled.  As long the SW was registered, regardless of SW enable state, shift-reloads could get the page to load; regular reloads, or regular page visits (including typing URLs into the address bar), got hung.

Comment 13

[Eric A. Meyer]

Interesting followup: I left SWs disabled, and went about my day.  A few minutes ago, I tried to go to medium.com, and it hung.  I opened about:config, and dom.serviceWorkers.enabled was still false.  I closed the still-hung medium.com tab, made sure I didn’t have any other tabs open to medium.com (I didn’t), and then enabled SWs.  When I loaded up about:serviceworkers, it showed that I had a SW for medium.com.  I am pretty confident that I didn’t have one after my last round of testing (described in comment #12), and as I say, I left SWs disabled after I was done.

Comment 14

[(no longer active)]

So far, I have found out that inserting an entry into the cache for https://medium.com/service-worker.js is failing with:

The SQL statement \'INSERT INTO entries (request_method, request_url_no_query, request_url_no_query_hash, request_url_query, request_url_query_hash, request_referrer, request_headers_guard, request_mode, request_credentials, request_contentpolicytype, request_cache, request_body_id, response_type, response_url, response_status, response_status_text, response_headers_guard, response_body_id, response_security_info_id, response_principal_info, response_redirected, response_redirected_url, cache_id ) VALUES (:request_method, :request_url_no_query, :request_url_no_query_hash, :request_url_query, :request_url_query_hash, :request_referrer, :request_headers_guard, :request_mode, :request_credentials, :request_contentpolicytype, :request_cache, :request_body_id, :response_type, :response_url, :response_status, :response_status_text, :response_headers_guard, :response_body_id, :response_security_info_id, :response_principal_info, :response_redirected, :response_redirected_url, :cache_id );\' could not be compiled due to an error: table entries has no column named response_principal_info

My database's version is 14.  The entries table is like the following:

CREATE TABLE entries (
  id INTEGER NOT NULL PRIMARY KEY,
  request_method TEXT NOT NULL,
  request_url_no_query TEXT NOT NULL,
  request_url_no_query_hash BLOB NOT NULL,
  request_url_query TEXT NOT NULL,
  request_url_query_hash BLOB NOT NULL,
  request_referrer TEXT NOT NULL,
  request_headers_guard INTEGER NOT NULL,
  request_mode INTEGER NOT NULL,
  request_credentials INTEGER NOT NULL,
  request_contentpolicytype INTEGER NOT NULL,
  request_cache INTEGER NOT NULL,
  request_body_id TEXT NULL,
  response_type INTEGER NOT NULL,
  response_url TEXT NOT NULL,
  response_status INTEGER NOT NULL,
  response_status_text TEXT NOT NULL,
  response_headers_guard INTEGER NOT NULL,
  response_body_id TEXT NULL,
  response_security_info_id INTEGER NULL REFERENCES security_info(id),
  response_redirected INTEGER NOT NULL,
  response_redirected_url TEXT NOT NULL,
  cache_id INTEGER NOT NULL
REFERENCES caches(id) ON DELETE CASCADE)

The response_principal_info column was added in bug 1169044 without bumping the DB version, and I reviewed that.  Sorry, I screwed up.  :(

Comment 15

[(no longer active)]

Attachment: Bump the caches.sqlite version numbers because of the field that was added in bug 1169044

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/012f4ec8e2a6

Comment 17

[Ben Kelly [:bkelly, not reviewing]]

In theory we should do a migration, but lets go with the wipe version bump on this one since its breaking people in the wild.

Comment 18

[(no longer active)]

Comment on attachment 8631316 [details] [diff] [review]
Bump the caches.sqlite version numbers because of the field that was added in bug 1169044

Approval Request Comment
[Feature/regressing bug #]: Bug 1169044
[User impact if declined]: medium.com (and possibly other websites) won't load.
[Describe test coverage new/current, TreeHerder]: Locally.
[Risks and why]: This is very low risk.
[String/UUID change made/needed]: None.

Comment 19

[Tim Taubert [:ttaubert] (inactive)]

So does that mean we should be better at handling DB failures that might occur for whatever reason?

Comment 20

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Tim Taubert [:ttaubert] from comment #19)
> So does that mean we should be better at handling DB failures that might
> occur for whatever reason?

Yes.  Ehsan filed bug 1181887 for that.

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/012f4ec8e2a6

Comment 22

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tim, Ehsan: Could you please confirm that the fix from the nightly build works for you? Once verified, I will approve for uplift. 

Adding a tracking flag for FF41.

Comment 23

[(no longer active)]

This patch missed today's Nightly.  I will have to wait until tomorrow to test it.

Comment 24

[(no longer active)]

medium.com started to work for me as soon as I updated to today's Nightly.

Comment 25

[Eric A. Meyer]

I’m also getting consistent loading of medium.com.  That’s with SWs enabled, and with an SW for medium.com listed in about:serviceworkers.  This feels fixed!

Comment 26

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8631316 [details] [diff] [review]
Bump the caches.sqlite version numbers because of the field that was added in bug 1169044

Thanks for the verification Ehsan. Approving for uplift to Aurora.

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/345515d8197b