The Rust get_if_addrs library previously used does not build on Android with
our build system. Since we're already using nICEr to determine the local
interface addresses, rather than fix the Rust library, we can use those
addresses to set the interface on which mdns_service listens.
Differential Revision: https://phabricator.services.mozilla.com/D42760
--HG--
extra : moz-landing-system : lando
Checking this assertion outside of the if statement can result in
a use-after-free in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D42152
--HG--
extra : moz-landing-system : lando
The current code causes one mDNS service to be created for each PeerConnection.
Due to Bug 1569311, the services persist until shutdown, which can lead to a
lot of mDNS threads running on sites which use WebRTC for fingerprinting. This
change makes it so we start at most one mDNS service.
I've filed Bug 1569955 to look at shutting down the mDNS service after the
last hostname is unregistered. As an alternative, if we fix Bug 1569311, we
could also use refcounting and stop the mDNS service after the last
StunAddrsRequestParent is freed.
Differential Revision: https://phabricator.services.mozilla.com/D42151
--HG--
extra : moz-landing-system : lando
With the move to the socket process, the UUID service is no longer available
in nricectx. This adds a pair of helper functions to mdns_service to generate
UUIDs and uses them to generate hostnames inside nricectx.
Differential Revision: https://phabricator.services.mozilla.com/D42150
--HG--
extra : moz-landing-system : lando
This only enables mDNS on OS X for now. Some versions of Windows lack mDNS
support, there are some oddities with resolving IPv6 addresses on Linux, and
Android has not yet been tested. All of these will be addressed in follow on
bugs.
Differential Revision: https://phabricator.services.mozilla.com/D38496
--HG--
extra : moz-landing-system : lando
This adds a mdns_service to mtransport to handle responding to mDNS queries.
All hostnames will be generated from UUIDs, so the responder assumes that it
is the only responder for a hostname which is registered with it. Because of
this, the responder does not first make a DNS query itself to see if any other
responder is handling a hostname, and does not wait a random amount of time
before replying, both of which are required by the specification to avoid
collisions with other responders.
Differential Revision: https://phabricator.services.mozilla.com/D38489
--HG--
extra : moz-landing-system : lando
This removes these functions: bind, getaddrinfo, recvfrom, sendto, setsockopt,
socket from the check_networking test to allow for their use by the Rust mDNS
responder.
Differential Revision: https://phabricator.services.mozilla.com/D38488
--HG--
extra : moz-landing-system : lando
This gives control of the graph's lifetime to main thread. Not being in gGraphs
means it's not meant to be used for any new streams as it will irreversibly be
shutting down.
This obsoletes GraphDriver::Revive.
Differential Revision: https://phabricator.services.mozilla.com/D43663
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/70NFnet82cU
This commit introduces a new mathml.xlink.disabled option to disable support
for XLink attributes on MathML elements together with a use counter and
deprecation warning when support is enabled. For now, support is only disabled
in Nighly.
In the past, we relied on custom MathML deprecation warnings but those are
removed here. Corresponding tests for these legacy warning messages are
also removed from test_bug553917.html.
link-1.xhtml is run with XLink support enabled (since it check xlink:href)
while browser_contentAltClick.js is updated to check whether XLink has any
effect on MathML, depending on whether the option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D43332
--HG--
extra : moz-landing-system : lando
