The rejection process consumes the ErrorResult, so an rvalue reference is the honest thing here.
Differential Revision: https://phabricator.services.mozilla.com/D62632
--HG--
extra : moz-landing-system : lando
- Cleaned up some comments.
- Changed some const nsACString& parameter types to nsCString to accept r-value
and l-value nsCStrings.
Differential Revision: https://phabricator.services.mozilla.com/D58877
--HG--
extra : moz-landing-system : lando
- Remove `ServiceWorkerRegistration`s' pending uninstall flag.
- Rename `ServiceWorkerRegistrationListener`'s `RegistrationRemoved` method to
`RegistrationCleared`; registrations are no longer necessarily consider
invalid when they are removed from the "scope to registration map", but rather
when they're both removed from the map and not controlling clients (at which
point `Clear` is called).
- Maintain the invariant that no `ServiceWorkerRegistrationInfo` in
`ServiceWorkerManager::RegistrationDataPerPrincipal::mInfos` (i.e. the "scope
to registration map") is in the unregistered state. Assertions check this in
`ServiceWorkerManager::AddScopeAndRegistration` and
`ServiceWorkerRegistrationInfo::SetUnregistered`.
- Fix some incorrect web platform tests.
Differential Revision: https://phabricator.services.mozilla.com/D38684
--HG--
extra : moz-landing-system : lando
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
Currently, we are required to fire updatefound in three cases:
* When a "soft" update finds an update.
* When a call to ServiceWorkerRegistration.update finds an update.
* When ServiceWorkerContainer.register registers a ServiceWorker.
In the first case, there are no requirements on the timing of the event. For
the second two cases, however, the promise returned by update or register
needs to resolve before updatefound is dispatched. We hack around the first
case by explicitly counting the calls to update and only dispatching
updatefound when the final promise resolves. In the case of SWC.register, the
ServiceWorkerRegistration object might not even exist when it notices that we
need to fire updatefound, which suggests that we need some code to tell it
when to fire the event; except that in the soft update case, there is no
obvious place to do so. So, the easiest way to resolve this is to have the
parent process tell the ServiceWorkerRegistration when to fire updatefound
itself. This way, we don't rely on any tricky timing and everything is
consistent with itself.
Differential Revision: https://phabricator.services.mozilla.com/D13368
--HG--
extra : moz-landing-system : lando
Yaron Tausky
Boris Zbarsky
Perry Jiang
Andrea Marchesini
Jean-Yves Avenard
Sylvestre Ledru
Blake Kaplan
Ben Kelly