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
JSEP transceivers were previously held in a vector, in the order that they were
created. However, these could be removed, which meant that the indexing was not
stable. Under most circumstances this did not matter, however there was a
wrinkle with implicit rollback in repeated sRD. Re-applying a remote offer that
had created a transceiver would destroy that transceiver, and create a new one
to replace it. However, JS was not informed, because to PeerConnectionImpl it
looked like nothing had changed. Now, transceivers are indexed in a stable way,
which allows this bug to be fixed, and makes things a little less confusing.
Differential Revision: https://phabricator.services.mozilla.com/D70400
JSEP transceivers were previously held in a vector, in the order that they were
created. However, these could be removed, which meant that the indexing was not
stable. Under most circumstances this did not matter, however there was a
wrinkle with implicit rollback in repeated sRD. Re-applying a remote offer that
had created a transceiver would destroy that transceiver, and create a new one
to replace it. However, JS was not informed, because to PeerConnectionImpl it
looked like nothing had changed. Now, transceivers are indexed in a stable way,
which allows this bug to be fixed, and makes things a little less confusing.
Differential Revision: https://phabricator.services.mozilla.com/D70400
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
With transport-cc enabled, we get feedback calls into AudioSendStream occuring
on the sts thread. Since AudioSendStream is constructed on the main thread,
this trips up the worker_thread_checker_ checks. The functions that are called
end up doing their work using AudioCodingModuleImpl::ModifyEncoder, which
takes a lock, so it should be safe to remove these assertions.
We've had to do similar things to ChannelProxy in the past to get stats
working from the sts thread. ChannelProxy has been removed upstream, but we
should consider changing our use of AudioSendStream with the next libwebrtc
update so that is always called from the same thread.
Differential Revision: https://phabricator.services.mozilla.com/D72157
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
Pick commits:
9caa5b1 - Only print the filename when logging (#581)
8a4170a - sun: Line continuation character not needed
9696902 - sun: POLL_TIMEOUT is no longer used
159fb99 - sun: Add my email address to the copyright header.
e3b409f - sun: Refactoring: reduce duplication in stream structure.
36aa8b1 - sun: Make the purpose of some variables clearer.
1654468 - sun: Update header inclusion.
38ef439 - sun: Convert floats to LINEAR32 instead of LINEAR16
4dbacae - Remove test for registering device changed callback twice
7f94e27 - Force Rust builds to always rerun cargo.
3e23b25 - Remove TODO, we've done all of those, or they don't apply anymore
Differential Revision: https://phabricator.services.mozilla.com/D70546
--HG--
extra : moz-landing-system : lando
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
Emptiness of values should be checked using the `empty` method, and not
by comparing the size to 0. Fix such case in the code of
ClearKeyDecryptionManager.cpp module.
Differential Revision: https://phabricator.services.mozilla.com/D70206
--HG--
extra : moz-landing-system : lando
Byron Campen [:bwc]
Matthew Gregan
Dan Minor
Paul Adenot
Simon Giesecke
Razvan Maries
Nico Grunbaum
Arthur Iakab
Kershaw Chang
Sylvestre Ledru
Michael Froman
Narcis Beleuzu
shravanrn@gmail.com
Brindusan Cristian
Chun-Min Chang
Jan Beich
Nils Ohlmeier [:drno]
Omri Sarig
Noemi Erli