alertsettingscallback only goes to the single observer whereas notifications-open-settings goes through the global observer service.
--HG--
extra : commitid : chMffpyqlT
extra : rebase_source : 35ff4a94fbf14899002a6f2395063bbdc124ff48
alertsettingscallback only goes to the single observer whereas notifications-open-settings goes through the global observer service.
--HG--
extra : commitid : BC7Pj6kNtNN
extra : rebase_source : 95170c48ae4fa852d1a87c82fc486e70a945fc7a
alertsettingscallback only goes to the single observer whereas notifications-open-settings goes through the global observer service.
--HG--
extra : commitid : 2akA3IUQCkx
extra : rebase_source : 40d5758f465fdf1b3e911584c4d9403c572f4a88
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
--HG--
extra : commitid : 5dtc2E63kuM
extra : rebase_source : 4265dcd154462aa4f3b915e9e898fe7b82bf9afc
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.
--HG--
extra : commitid : BnnijSibVYe
extra : rebase_source : 15f6810dfbd0c88a983196de401c55e782b1d1d8
When we use the XUL based alerts and the main firefox window is closed, the XUL
window still keeps the process running, but as the window closes it calls
DisconnectFromOwner() on the Notification. Later, when the XUL alert closes
(either due to timeout or due to script) attempts to get the principal can
fail. This patch allows that to happen and will just skip deleting the
Notification from persistent storage.
--HG--
extra : commitid : 9VuWbVu7mVk
extra : rebase_source : bfa6deecf217a3a20ceef524e4d2efd361de8e98
Rather than store a non-thread-safe refcounted nsIStructuredCloneContainer, store the base64 representation.
Caches a jsval the first time an attempt to access data is made from content script.
--HG--
extra : commitid : Ijd82LTJaYo
extra : rebase_source : f82e837842037ea02efae3a0fc9b2b35c2a0d7d0
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.
--HG--
extra : rebase_source : 52d3864fb39aa892d2f70dc2b71f09fb0d2ba533
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Does not implement the Service Worker API - https://notifications.spec.whatwg.org/#service-worker-api
***
Folded:
Bug 916893 - Better ownership model. r=khuey
Fix for bug found by ASan where we were touching the NotificationFeature after releasing it.
--HG--
extra : transplant_source : %3C%09F%99%CASF%1A%25%89X%D9%8C%0B%FAu%9D%27%E8w
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.
--HG--
extra : rebase_source : 1becb5055dc29166dc6445227bab4b9daed213cf
Does not implement the Service Worker API - https://notifications.spec.whatwg.org/#service-worker-api
***
Folded:
Bug 916893 - Better ownership model. r=khuey
Fix for bug found by ASan where we were touching the NotificationFeature after releasing it.
--HG--
extra : rebase_source : 7522a4a51fda41726e7cf26b61fbf535c260fab3