All uses are always the main thread and its derivative (obtained via EventTargetFor method) or nullptr.
Depends on D80421
Differential Revision: https://phabricator.services.mozilla.com/D80422
Includes removing an error code for a function that never fails, and removing
an error return when the function successfully did what it said it would.
Differential Revision: https://phabricator.services.mozilla.com/D78929
We currently retry sending queries on all failures to write to the socket on
the assumption that write errors represent transient errors. With this change,
we treat EPERM has a permanent error and drop queries if we see it. This is
not a problem when sending answers, as we don't retry in case of errors there,
on the assumption that the other side will retry their query in the future.
We do have code to limit the number of times we attempt an mDNS query, but we
didn't hit it in this case, because it only counts sends that are successful.
Differential Revision: https://phabricator.services.mozilla.com/D73492
If we're shutting down and mSocketThread is no longer accepting work,
this dispatch can fail. As far as I can see, fully fixing this would
require changes to nsIThread in order to allow checking whether the
thread is shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D71964
If we're shutting down and mSocketThread is no longer accepting work,
this dispatch can fail. As far as I can see, fully fixing this would
require changes to nsIThread in order to allow checking whether the
thread is shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D71964
If we're shutting down and mSocketThread is no longer accepting work,
this dispatch can fail. As far as I can see, fully fixing this would
require changes to nsIThread in order to allow checking whether the
thread is shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D71964
In rare cases, the random number generator can fail to initialize when
generating a v4 UUID, causing a panic and crash. This adds code to catch that
panic and return a nil (all zeros) UUID instead. Using a nil UUID seems better
from a user privacy perspective than failing to obfuscate the host address and
leaking it when it is expected to be hidden.
Longer term, we might want to switch over to using nsIUUIDGenerator, but that
would require changes to how the socket process is initialized.
Differential Revision: https://phabricator.services.mozilla.com/D70172
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
This patch makes nsIDNSByTypeRecord extend nsIDNSRecord, but implementations
will safely forward the nsIDNSRecord methods to `nullptr`, meaning they will
throw an error when called.
Consumers should try to QI the nsIDNSRecord to nsIDNSByTypeRecord (or any
future types) and use that.
Differential Revision: https://phabricator.services.mozilla.com/D69326
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
This allows us to continue adding remaining interfaces from addrs array and
makes sure nr_interface_prioritizer_sort_preference() is called at the end.
Differential Revision: https://phabricator.services.mozilla.com/D66941
--HG--
extra : moz-landing-system : lando
Enable the NSS workaround introduced in bug 1619102, for DTLS 1.3 WebRTC clients.
Differential Revision: https://phabricator.services.mozilla.com/D66094
--HG--
extra : moz-landing-system : lando