1242056 - Specific profile fails to install service worker with TypeError

Status: RESOLVED INCOMPLETE

(Core :: DOM: Service Workers, defect, P3)

Description

[Edwin Wong [:edwong]]

I'm on Win7 VMFusion instance on a MBP.  I have an old old install of FxBeta and i upgraded multiple times till i got to Fx44.

1. goto: 
https://people.mozilla.org/~ewong2/push-notification-test/
2. click 'register Service worker'

actual:
Registration failed: TypeError: ServiceWorker script at https://people.mozilla.org/~ewong2/push-notification-test/service-worker.js for scope https://people.mozilla.org/~ewong2/push-notification-test/ encountered an error during installation.

work around: a new profile doesn't demonstrate this problem and install the SW just fine.

Comment 1

[Edwin Wong [:edwong]]

here's that profile: http://people.mozilla.org/~ewong2/push/fzkocxpw.default.zip

Comment 2

[Edwin Wong [:edwong]]

NI: overholt - not sure if this is just testers upgrading or more win users getting an error on install.

Comment 3

[Andrew Overholt [:overholt]]

Can you fix the permissions on the profile? "You don't have permission to access /~ewong2/push/fzkocxpw.default.zip on this server."

I don't know what would be causing this but I'll take a look with the profile. Maybe Ben or Ehsan know off the top of their head(s), though.

Comment 4

[(no longer active)]

It's hard to say without being able to access the profile.

Comment 5

[Edwin Wong [:edwong]]

fixed the permissions, download away!

Comment 6

[(no longer active)]

I cannot reproduce.  This is what I tried:

1. Download and unzip the profile.
2. Run Firefox with that profile.
3. Go to https://people.mozilla.org/~ewong2/push-notification-test/ and click "register service worker".

Comment 7

[(no longer active)]

Hmm, I can reproduce on 44 release, but not on Nightly...

I need to get a build going to see what's going on in 44.

Comment 8

[Andrew Overholt [:overholt]]

Ben Bangert and Edwin told me this was a profile that was used with nightly and then failed with release so there may be some other stuff here like idb schema changes or something going on.

Comment 9

[Edwin Wong [:edwong]]

re: comment #7 - yes I can only repro on Fx44 NOT on Nighly46 on Win10 (vmwareFusion)

Comment 10

[(no longer active)]

This is the cache database schema mismatch caused by the downgrade.

I think maybe it makes sense to fall back to not using the cache instead of completely giving up doing anything, especially that the use of the Cache API here is completely hidden from the user.  Investigating how simple a fix would be...

Comment 11

[(no longer active)]

I see three alternatives here:

1. Do nothing.
2. Create a special mode in which SetupAction will recreate the database schema if the existing version is too new, and trigger that from CompareManager.
3. In CompareManager, if the caches.open() promise rejects, pretend that the comparison's result was false, and register the SW (without putting it in the cache.)

(3) sounds bad to me, since we'd be violating the spec.  I'm personally fine with either #1 or #2.  Ben, what do you think?

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

What does IDB do with going backwards on schema?  We should probably just do the same.

I think my inclination would be to spam the web console with a message and do nothing.  Ideally firefox would have some UX indicating that a future profile is being opened in an old browser and things are going to be hit-or-miss.

Comment 13

[(no longer active)]

(In reply to Ben Kelly [:bkelly] from comment #12)
> What does IDB do with going backwards on schema?  We should probably just do
> the same.

AFAIK IDB is the only other thing in the platform that doesn't support downgrades, everything else supports downgrades.  (Note that I'm not necessarily advocating for or against supporting downgrades here.)

> I think my inclination would be to spam the web console with a message and
> do nothing.  Ideally firefox would have some UX indicating that a future
> profile is being opened in an old browser and things are going to be
> hit-or-miss.

Well, using profiles from the future is mostly fine.  But more to the point, warning to the console about what's going on is definitely better than our current behavior (failing silently).  I'll do that.

Comment 14

[(no longer active)]

The new thinking here is that we need something beyond just a console error.  Most likely, ignoring what's in the cache and re-fetching the service worker script...

Comment 15

[Myk Melez [:myk] [@mykmelez]]

I see this in my regular profile with the latest Nightly, so presumably it's a different issue (which I filed as bug 1322569).

However, note that this issue does seem to be encountered by developers:

"Turns out this is due to https://bugzilla.mozilla.org/show_bug.cgi?id=1242056 in which the current production Firefox isn't happy if you've also used the Nightly Firefox to view a site with the same service worker." - https://github.com/GoogleChrome/ioweb2016/issues/603

"… tried Firefox Stable which simply reported "TypeError: ServiceWorker script at https://localhost:60000/sw.js for scope https://localhost:60000/ encountered an error during installation. <unknown>" and confused me even more, and then gave up and spent the rest of the day only working in Chrome." - https://www.scirra.com/blog/ashley/27/service-workers-are-a-pain-in-the-ass

Comment 16

[Marion Daly [:mdaly]]

Ehsan: Okay if I remove you from this bug?

Comment 17

[Jens Stutte [:jstutte]]

Perry, I assume that the situation might have changed since then a bit. Can you check?

Comment 18

[Perry Jiang [:perry] [no longer employee, use ni?]]

Unfortunately we can't do a test now because the SW/website linked in the bug description no longer exists, but maybe we can close this bug given lack of activity, and if the problem exists elsewhere hopefully it would be reported/exists with up-to-date STR.