Callers should pass in UTF-8, since that's what the JS engine ends up with in the end anyway.
The various URL changes are because NS_NewURI converts incoming nsAString to
UTF-8 anyway. So we might as well do that up-front and then use the UTF-8
string for both the NS_NewURI call and the error-reporting if it fails.
Differential Revision: https://phabricator.services.mozilla.com/D65543
--HG--
extra : moz-landing-system : lando
ServiceWorkerRegistration::UpdateState can call content code, which
in turn can result in the registrations getting deleted. This
commit moves the call outside the constructor, so the
registration's creator has a chance to get a proper RefPtr to it.
Differential Revision: https://phabricator.services.mozilla.com/D61706
--HG--
extra : moz-landing-system : lando
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
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
This is effectively a reversion of the change made in
https://hg.mozilla.org/mozilla-central/rev/89c938649297#l1.39 when
DOMMozPromiseRequestHolder was introduced. I've tried to add some
comments to contextualize what's happening there and why it differs
from other similar callsites.
Longer term we might move to just deleting the underlying actor when
we are disconnected. Those actors were written assuming an
execution model where letting either end delete the actor would result
in intentional process crashes when a message was received for a
destroyed actor. That is no longer the case.
Differential Revision: https://phabricator.services.mozilla.com/D49671
--HG--
extra : moz-landing-system : lando
- Throw a TypeError when a registration isn't found in the "scope to registration map"
- Synchronously (before enqueuing a job) check for an existing newest worker
- Synchronously check if an installing worker is attempting to update itself
Differential Revision: https://phabricator.services.mozilla.com/D41618
--HG--
extra : moz-landing-system : lando
- Throw a TypeError when a registration isn't found in the "scope to registration map"
- Synchronously (before enqueuing a job) check for an existing newest worker
- Synchronously check if an installing worker is attempting to update itself
Differential Revision: https://phabricator.services.mozilla.com/D41618
--HG--
extra : moz-landing-system : lando
- Throw a TypeError when a registration isn't found in the "scope to registration map"
- Synchronously (before enqueuing a job) check for an existing newest worker
- Synchronously check if an installing worker is attempting to update itself
Differential Revision: https://phabricator.services.mozilla.com/D41618
--HG--
extra : moz-landing-system : lando
- Throw a TypeError when a registration isn't found in the "scope to registration map"
- Synchronously (before enqueuing a job) check for an existing newest worker
- Synchronously check if an installing worker is attempting to update itself
Differential Revision: https://phabricator.services.mozilla.com/D41618
--HG--
extra : moz-landing-system : lando
- Throw a TypeError when a registration isn't found in the "scope to registration map"
- Synchronously (before enqueuing a job) check for an existing newest worker
- Synchronously check if an installing worker is attempting to update itself
Differential Revision: https://phabricator.services.mozilla.com/D41618
--HG--
extra : moz-landing-system : lando
The previous implementation checked for a registration's active worker on the
main thread using `ServiceWorkerManager::GetRegistration`. This has two
problems:
- `ServiceWorkerManager` can't be relied upon in parent-intercept mode, and
- `SWM:GetRegistration` won't return the registration if `.unregister()` has
been called.
Differential Revision: https://phabricator.services.mozilla.com/D40104
--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
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
The logic here to move our check was right, but our check was wrong.
Also, we landed a test that checked for our wrong implementation.
We need to correct our implementation and re-think the test. The
right test might just be a mochitest, possibly with some Firefox-only
hooks involved.
--HG--
extra : rebase_source : 4d6b9a120adcee835f626098e8547c440a39f595
I guess because, in the old world, registrations were propagated everywhere we
could end up in a state with an old ServiceWorkerRegistrationInfo while our
ServiceWorkerRegistration thought that everything was up to date. I think that
what should eventually happen will be that when we eventually get our updated
Info, we'll update the state of the ServiceWorkerRegistration accordingly and
things should work themselves out.
Differential Revision: https://phabricator.services.mozilla.com/D2077
--HG--
extra : moz-landing-system : lando
