Report to console if service worker script cannot be installed because dom/cache fails to open due to future schema version

NEW
Unassigned

Status

()

defect
P3
normal
3 years ago
9 months ago

People

(Reporter: benlast, Unassigned)

Tracking

(Depends on 1 bug, Blocks 2 bugs)

45 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: btpp-fixlater)

Attachments

(3 attachments)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36

Steps to reproduce:

Try to register a service worker script that fails.


Actual results:

The navigator.serviceWorker.register promise rejects with "TypeError: ServiceWorker script at <url here> for scope <scope here> encountered an error during installation." There is no further information on what error was encountered, making it extremely difficult to diagnose the failre.


Expected results:

Indicate the nature of the error (network? parsing? exception?) and the location.
Flags: needinfo?(bkelly)
Posted image failed_register.png
This is reported to the console.  Please see the attached screenshot from FF45.0.2.
We report this information to the console instead of in the rejection value because its useful in cases where the register() promise is not rejected.  For example, this attached screenshot shows an error that occurs during the handling of the install event.  The register() promise is already settled successfully by the time we fire the install event.
Posted image update_failed.png
And things like syntax errors can occur during updates which may not have any promise attached to them at all.  For example, in this attached screenshot.  Reporting to the console ensures they are visible in a consistent manner.
However, I do see we don't report anything to the console if the service worker script 404s.  That's a problem we should fix.  I filed bug 1267473 for this.

We have a similar issue if the service worker script has a bad mime type.  See bug 1233798.

Do you have a different error you ran into not covered by one of these cases?  Thanks!
Flags: needinfo?(bkelly) → needinfo?(benlast)
Hi Ben

All that was reported to the console in my case was the rejection that was logged by my code. There was no other report of any error. So there is at least one case in which the registration fails that does not cause a console log.

Unfortunately, I can't reproduce the problem any more. Changing profiles in FF stopped the error happening, and now even the original profile in which it occurred works. I don't have any more information on why it was happening, but it was consistently failing.
Flags: needinfo?(benlast)
Hi Ben

The problem is occurring again in a FF config I have here. Console log output:

redirect() webpush-host-client.js:23:425
registerServiceWorker( "https://webpush-staging.mobify.net/service-worker.js?site_id=webpush-staging&version=2.2.7.2&hash=2e6b5e9a" ) webpush-host-client.js:23:425
GET 
https://webpush-staging.mobify.net/service-worker.js [HTTP/1.1 200 OK 184ms]
GET 
https://webpush-staging.mobify.net/favicon.ico [HTTP/1.1 200 OK 89ms]
Could not register service worker:  "TypeError: ServiceWorker script at https://webpush-staging.mobify.net/service-worker.js?site_id=webpush-staging&version=2.2.7.2&hash=2e6b5e9a for scope https://webpush-staging.mobify.net/ encountered an error during installation." webpush-host-client.js:23:425
Service worker did not become ready:  "TypeError: ServiceWorker script at https://webpush-staging.mobify.net/service-worker.js?site_id=webpush-staging&version=2.2.7.2&hash=2e6b5e9a for scope https://webpush-staging.mobify.net/ encountered an error during installation." webpush-host-client.js:23:425
redirectToMappedWebpushPage error:  "TypeError: ServiceWorker script at https://webpush-staging.mobify.net/service-worker.js?site_id=webpush-staging&version=2.2.7.2&hash=2e6b5e9a for scope https://webpush-staging.mobify.net/ encountered an error during installation." webpush-host-client.js:23:425
navigateTo: navigating to "https://webpush-staging.mobify.net/demo"

You can see the service worker file is downloaded (200 OK). All we get is the generic TypeError, with no further information about why the registration failed.
Will check when I get back to my desk.

What mimetype is the script being served with?
Flags: needinfo?(bkelly)
(venv)root:/pusheen# wget --server-response -O /dev/null 'https://webpush-staging.mobify.net/service-worker.js?site_id=webpush-staging&version=2.2.7.2&hash=2e6b5e9a'
--2016-04-28 18:12:22--  https://webpush-staging.mobify.net/service-worker.js?site_id=webpush-staging&version=2.2.7.2&hash=2e6b5e9a
Resolving webpush-staging.mobify.net (webpush-staging.mobify.net)... 54.172.238.29, 54.152.163.130
Connecting to webpush-staging.mobify.net (webpush-staging.mobify.net)|54.172.238.29|:443... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Cache-Control: s-maxage=300, max-age=300
  Content-Type: application/javascript; charset=utf-8
  Date: Thu, 28 Apr 2016 18:12:22 GMT
  Server: gunicorn/19.4.5
  Vary: Origin, X-Mobify-Webpush-Bundle, Cookie, Accept-Encoding
  Content-Length: 68243
  Connection: keep-alive
Length: 68243 (67K) [application/javascript]
Saving to: '/dev/null'

100%[=========================================================================================================================================>] 68,243       312KB/s   in 0.2s

2016-04-28 18:12:22 (312 KB/s) - '/dev/null' saved [68243/68243]
Is there any way for me to gain access to this site to test locally?

Have you used the same profile with different versions of firefix? For example going to nightly or dev edition, and then back to firefox release?
Flags: needinfo?(bkelly) → needinfo?(benlast)
Hi Ben

I emailed you directly about using the site to test.

I've been working in FF release pretty much exclusively for the last couple of days, but I just tested this: verify that my latest profile works, close FF and open Nightly with the same profile, verify that it works, close Nightly and go *back* to FF and verify that it still works. So it's not that using Nightly causes things to break.
Flags: needinfo?(benlast)
I verified that the profile in question has a future dom/cache schema version of 20.  Firefox 46 uses a cache schema version of 19.  Version 20 was introduced in FF47.

Note, you would have had to fully use the service worker for this origin in FF47+ in order to trigger database migration.

Anyway, we should log to the web console when we detect this.  Its a bit tricky since dom/cache doesn't know its being used for service worker scripts.  The ScriptLoader or ServiceWorkerScriptCache code would have to detect and surface the error to the console.

A better solution would be to do warn about this globally at the firefox browser level, but bug 1246615 doesn't seem to be going anywhere.
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Service Workers
Depends on: 1246615
Ever confirmed: true
Product: Firefox → Core
Summary: Service worker registration failure error is not useful → Report to console if dom/cache fails to open due to future schema version
Summary: Report to console if dom/cache fails to open due to future schema version → Report to console if service worker script cannot be installed because dom/cache fails to open due to future schema version
Whiteboard: btpp-fixlater
Duplicate of this bug: 1268954
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Priority: -- → P3
Assignee: bugmail → nobody
Blocks: 1482662
Status: ASSIGNED → NEW
Taking a look at this.

But, I guess we might also want to send warning messages to web console even just using Cache, IDB, and QM.
Also, the providing test couldn't be executed in the Debug build, because we might just hit the assertions.
Assignee: nobody → shes050117
Status: NEW → ASSIGNED
(In reply to Tom Tung [:tt] from comment #13)
Bug 1455707 is going to be resolved, so we will have a browser level warning to mitigate or fix this and also will have a dedicated profile per channel. Therefore, it's not really necessary to notify users that their schema version of databases for QM, IDB, and Cache are too new.

My concern here is that the warning message might not be connected to the failure of a service worker script installation. And, the possible solution might be defining a new internal error for having a future schema version in QuotaManager. Then, after propagating that error to a QuotaClient (e.g. Cache), it can either report the error to a console in its component or somehow let the script loader (seems to be CompareManager, IIUC) in ServiceWorker understand the reason for failing to load the sw script(as :bkelly said in comment #11, it's a bit tricky). However, this proposal is not really good, so I guess I need more time to consider about it.

Given things above, I'll leave this here for now.
Assignee: shes050117 → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.