When using add_task to schedule the tests, testEsniPushPart2 would always fail.
That's because Bug 1587875 now clears the DNS cache when the network.trr.uri
pref is changed. This is likely intermittent because of task scheduling.
This patch modernizes the test to use add_task and promises, and sets the
network.trr.clear-cache-on-pref-change;true pref so the test performs its
checks properly.
Differential Revision: https://phabricator.services.mozilla.com/D52825
--HG--
extra : moz-landing-system : lando
Fix style consistency while at it and a couple of constness issues.
Depends on D52503
Differential Revision: https://phabricator.services.mozilla.com/D52505
--HG--
extra : moz-landing-system : lando
The information is now passed to the parent channel once replacement is completed.
Depends on D52262
Differential Revision: https://phabricator.services.mozilla.com/D52263
--HG--
extra : moz-landing-system : lando
We can guarantee that those callbacks will occur prior the call to OnStartRequest.
By running them all on the PHttpChannel we remove the potential race between the PHttpChannel which runs on the main thread and PHttpBackroundChannel which runs on the necko thread.
Depends on D52261
Differential Revision: https://phabricator.services.mozilla.com/D52262
--HG--
extra : moz-landing-system : lando
Remove the need to create separate runnable classes. It's far more readable and remove the need to duplicate lots of code.
We unfortunately need to capture "this" in a ref counter to get around the static analyzer complaining about capturing this by value, even thouch the ChannelEventQueue guarantees that this will outlive the event.
Depends on D52260
Differential Revision: https://phabricator.services.mozilla.com/D52261
--HG--
extra : moz-landing-system : lando
PrepentEvent was already moving the argument passed by reference. This makes it clear that the object will be moved.
Differential Revision: https://phabricator.services.mozilla.com/D52260
--HG--
extra : moz-landing-system : lando
This code was added in bug 465158 to deal with on-demand dial-up
connections. That scenario is hopefully not common anymore.
One benefit of the code was that it excludes network adapters
that share the computers network from being part of network
change notifications, network ID, etc. However, the code assumed
that only adapters with the address 192.168.0.1 would be a ICS
adapter, but trying to set up ICS on Windows 10 actually set the
LAN interface with 192.168.137.1 - so that assumption isn't
valid anymore. So the code is likely not even running for
adapters that are ICS. It may run for adapters which have the
IP 192.168.0.1, but probably that's quite rare as that's more
often a gateway IP than a client IP.
In any case, it's better to just get rid of it and if needed,
however unlikely, we'll replace it with a more modern API.
Depends on D52573
Differential Revision: https://phabricator.services.mozilla.com/D52574
--HG--
extra : moz-landing-system : lando
Old code needed to dynamically load a DLL - which was not available
for windows versions prior to Vista, and if that failed it would
fall back to using an older API.
This patch now calls the methods directly, since we don't have to
worry about the library not being there; we also remove the
fallback, meaning we always call NotifyIpInterfaceChange instead
of falling back to NotifyAddrChange.
Differential Revision: https://phabricator.services.mozilla.com/D52573
--HG--
extra : moz-landing-system : lando
Instead of spinning up a LazyIdleThread for this check, just use the background thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D52240
--HG--
extra : moz-landing-system : lando
The already-landed patches contained a spelling error. This patch fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D51390
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
Socket Thread and Worker Threads use custom event loops and don't wait in
calls to ProcessNextEvent all the time; this can lead to odd Responsiveness numbers.
Differential Revision: https://phabricator.services.mozilla.com/D51835
--HG--
extra : moz-landing-system : lando
Previously we had no way from excluding just one channel from TRR mode3.
The solution was to add the captive portal domain to the exclusion list.
Now the captive portal channel is marked with nsIRequest.DISABLE_TRR_MODE so
the exclusion is not necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D48820
--HG--
extra : moz-landing-system : lando
* Makes it possible to selectively enable TRR for pbmode/container/window/etc
Differential Revision: https://phabricator.services.mozilla.com/D48363
--HG--
extra : moz-landing-system : lando
This mainly shows up when creating a DocumentChannel for a blob URI, and then we try switch to the 'real' blob channel and can't find an nsIChildChannel.
We could instead implement an IDPL parent/child class for this (like FileChannelChild/Parent), but the implementation of those is effectively the same (just call AsyncOpen from CompleteRedirectSetup), and I think is unnecessary boilterplate, since we can't have an actual redirect to a blob URI.
Differential Revision: https://phabricator.services.mozilla.com/D51903
--HG--
extra : moz-landing-system : lando
Determining link status from states and addresses of the individual interfaces isn't always reliable. With this patch we assume the link is up when we could find a route for kRouteCheckIPv4 host or kRouteCheckIPv6 host.
Differential Revision: https://phabricator.services.mozilla.com/D52027
--HG--
extra : moz-landing-system : lando
Socket Thread and Worker Threads use custom event loops and don't wait in
calls to ProcessNextEvent all the time; this can lead to odd Responsiveness numbers.
Differential Revision: https://phabricator.services.mozilla.com/D51835
--HG--
extra : moz-landing-system : lando
Determining link status from states and addresses of the individual interfaces isn't always reliable. With this patch we assume the link is up when we could find a route for kRouteCheckIPv4 host or kRouteCheckIPv6 host.
Differential Revision: https://phabricator.services.mozilla.com/D52027
--HG--
extra : moz-landing-system : lando
Valentin Gosu
Victor Porof
Sebastian Streich
Sylvestre Ledru
Narcis Beleuzu
Jean-Yves Avenard
Dragana Damjanovic
Matt Woodrow
Dorel Luca
Kristen Wright
ffxbld
Paul Bone
Bogdan Tara
Randell Jesup
Michal Novotny
Ciure Andrei
Paul Zuehlcke
Coroiu Cristina