Contact emails
Engineering: nhi...@chromium.org, mlam...@chromium.org
(PM: kenji...@chromium.org)
Spec
Editor's draft (W3C Public Working Draft)
Summary
This intent to ship adds the following Interface and APIs to the Service Worker subset we already shipped:
openWindow() method on Clients
WindowClient/Client full-fledged interfaces
surfacing ServiceWorkerRegistration in the ServiceWorkerGlobalScope
API level detail (relevant changes in bold italic)
Use cases
These APIs enable Notifications and Push API use cases.
openWindow() allows you to open your website when the user acts on a notification for instance. It has some restrictions in place to prevent abuse, similar to restrictions for when an algorithm is “allowed to show a popup” in the HTML spec.
WindowClient/Client has attributes that let you find out if there is already a window opened to your website as well as methods for focusing on a particular window. Focusing has the same restrictions as openWindow().
Surfacing ServiceWorkerRegistration in the ServiceWorkerGlobalScope is needed for managing Push registrations. It also allows you to call showNotification within a push event handler.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS and Android, Android WebView)?
Yes.
Debuggability
There's a Service Worker section in chrome://inspect that provides an overview of all the Service Workers and lets you inspect them. You can even do remote debugging of a Service Worker on a mobile device. chrome://serviceworker-internals provides information for Chromium developers to debug and diagnose Service Worker issues. Also, M42 has more descriptive error messages in the console when Service Worker registration fails.
Compatibility Risk (SW side changes)
Pluses and minuses:
+ A third public working draft of the spec has been published on Feb 5th.
+ Mozilla is implementing Service Workers in Firefox, see bug 903441.
+ The team has been writing W3C testharness.js tests first, and only using Blink-specific tests for crashing, GC-related things and features that need manual testing. We plan to upstream the former kind to W3C.
- openWindow is not yet implemented in Firefox (main branch)
- (ServiceWorker)Clients/(ServiceWorker)Client are present but based on old definitions and therefore not compatible with our tests
- The spec is under active development. Relevant item for this intent to ship:
- some minor aspects of the openWindow restrictions are still being discussed: timeout value, scope of capability. Minimizing factor: we are taking a conservative stance by only allowing opening regular window and opting for a reasonable timeout value (the timeframe for allowing popups is actually described as user-agent defined in the HTML spec).
OWP launch tracking bug?
Link to entry on the feature dashboard
This is the most exciting thing to happen to the web platform since Service Workers. Can't +1 hard enough. My kingdom for an LGTM!
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
1. The openWindow() error handling does not seem to be quite per spec:
- It uses SyntaxError instead of TypeError for an invalid URL.
- The cross-origin SecurityError case does not seems to be in the spec.
- The spec references allowed to show a popup, but the implementation doesn't use UserGestureIndicator like most other instances of this concept that I'm aware of, like LocalDOMWindow::allowPopUp and Fullscreen::requestFullscreen. If the existing concept isn't usable, then the new concept needs to be standardized as well.
It looks like there aren't any tests for the error handling, but I could be looking in the wrong place.
2. Does "WindowClient/Client full-fledged interfaces" correspond to ServiceWorkerClientAttributes and thus include Client.url?
3. It looks like ServiceWorkerGlobalScope's readonly attribute ServiceWorkerRegistration registration is already unconditionally enabled.
As a general comment, it would be easier to evaluate an incremental Intent to Ship like this given the CLs which would make it so or have already made it so.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.