Per the product discussion, the Notification API should be disabled in
ServiceWorker in release builds for 42 since the UX isn't great [1].
The aim is to release in 44.
Apologies for the code duplication for pref checking in Notification and
ServiceWorkerRegistration. There isn't a easy way to get
ServiceWorkerRegistration's generated binding to include Notification.h without
having an attribute/method that uses Notification.
[1]: https://mana.mozilla.org/wiki/x/TgAJAw
Get rid of having users dispatch control runnables. It was error prone and
required too much reasoning. It was also possible to end up in a state where
callers would dispatch a WorkerRunnable, which would succeed, so they would not
dispatch a WorkerControlRunnable. Then the worker would stop Running,
canceling and releasing the runnable leading to releasing the proxy in an
unclean state. Instead, we AddRef() and add the feature and remove the feature
and Release() on Notify(). If callers successfully run a WorkerRunnable they
clean the proxy. If not, the proxy stays alive until the worker switches to
Canceling state.
Refactor creation and show dispatch so Notification constructor and showNotification can use it.
Move persistence to ShowInternal.
NotificationStorage calls callback async even when fetching from cache, simply to have similar semantics.
Calls to Notification::Get() are performed async since persistence is now async after being moved to ShowInternal().
Both are in accordance with the spec where the "append to list of notifications" operation is performed in the "show steps" which are performed in parallel from API invocations.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Refactor creation and show dispatch so Notification constructor and showNotification can use it.
Move persistence to ShowInternal.
NotificationStorage calls callback async even when fetching from cache, simply to have similar semantics.
Calls to Notification::Get() are performed async since persistence is now async after being moved to ShowInternal().
Both are in accordance with the spec where the "append to list of notifications" operation is performed in the "show steps" which are performed in parallel from API invocations.
Splits up the listener interface to which SWM can hold rawptrs so that registration objects living on the worker thread can use awkward proxies to listen to these events.
This patch exposes ServiceWorkerRegistration (and ServiceWorker to satisfy constraints) to workers.
For now, a null registration is returned in the worker.
This allows controller to track state too, and provides better encapsulation.
1) Move SW setup to SWM. RuntimeService now only creates the underlying SharedWorker.
2) Require a SWInfo to create a SW. The SW holds a refptr to the info.
Folded:
Various registration related UpdateState() calls and abort on failure to create a service worker.
Set ServiceWorker instances state based on corresponding ServiceWorkerInfo state.
Folded:
Allow file: serviceworkers
Registration fixes WIP
Queue updatefound instead of immediately firing
Initial "atomically" steps of registration should also be a part of the job
Fix some compiler errors
Be sure not to null out various workers too early during activation
Integrated ServiceWorkerGlobalScope::Update into the ServiceWorkerRegisterJob.
