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.
here's that profile: http://people.mozilla.org/~ewong2/push/fzkocxpw.default.zip
NI: overholt - not sure if this is just testers upgrading or more win users getting an error on install.
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.
Flags: needinfo?(overholt) → needinfo?(edwong)
It's hard to say without being able to access the profile.
fixed the permissions, download away!
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".
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.
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.
re: comment #7 - yes I can only repro on Fx44 NOT on Nighly46 on Win10 (vmwareFusion)
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...
Assignee: nobody → ehsan
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?
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.
(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.
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...
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
You need to log in before you can comment on or make changes to this bug.