It is likely that the test is flaky because we resolve the same host with a different TRR endpoint and sometimes we use a cached record.
We should clear the DNS cache before each test to ensure that we're actually checking the right thing.
Differential Revision: https://phabricator.services.mozilla.com/D24355
--HG--
extra : moz-landing-system : lando
Some testcases are chrome scope testcase hence the resources it loads are triggered by
"system principal". This will exempt the resource from classification.
So in this patch, we used a new window to for the tracker test frame.
The window creation code is referenced from test_privatebrowsing_trackingprotection.html.
Differential Revision: https://phabricator.services.mozilla.com/D22114
--HG--
extra : moz-landing-system : lando
This patch uses the flag to exempt channels from classification, but it
doesn't include the use cases of this flag.
See Bug 1442496 for the list of the call sites should use this flag.
Differential Revision: https://phabricator.services.mozilla.com/D22112
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
In this patch, we move from a model where URL classification is opt-in
(by specifying LOAD_CLASSIFIER_URI) to a model where it is enforced by
default unless a channel opts out or is deemed to be a critical channel
based on simple heuristics.
The heuristics exempt a channel from classification if it is triggered
by system with an exception when it is a top level load.
To ensure critical channels are never classified, we also exempt
channels which are flagged as "BeConservative" (implemented in bug 1321783).
Another load flag LOAD_BYPASS_URL_CLASSIFIER is also introduced
for the same reason.
Differential Revision: https://phabricator.services.mozilla.com/D22110
--HG--
extra : moz-landing-system : lando
nsDNSPrefetch holds a weak reference to nsHttpChannel. Weak references are not thread safe so, nsDNSPrefetch needs to be released on the main thread, in OnStopRequest.
Otherwise it gets released when the last reference to nsHttpChannel is dropped, which could be from another thread.
Differential Revision: https://phabricator.services.mozilla.com/D24174
--HG--
extra : moz-landing-system : lando
Some testcases are chrome scope testcase hence the resources it loads are triggered by
"system principal". This will exempt the resource from classification.
So in this patch, we used a new window to for the tracker test frame.
The window creation code is referenced from test_privatebrowsing_trackingprotection.html.
Differential Revision: https://phabricator.services.mozilla.com/D22114
--HG--
extra : moz-landing-system : lando
This patch uses the flag to exempt channels from classification, but it
doesn't include the use cases of this flag.
See Bug 1442496 for the list of the call sites should use this flag.
Differential Revision: https://phabricator.services.mozilla.com/D22112
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
In this patch, we move from a model where URL classification is opt-in
(by specifying LOAD_CLASSIFIER_URI) to a model where it is enforced by
default unless a channel opts out or is deemed to be a critical channel
based on simple heuristics.
The heuristics exempt a channel from classification if it is triggered
by system with an exception when it is a top level load.
To ensure critical channels are never classified, we also exempt
channels which are flagged as "BeConservative" (implemented in bug 1321783).
Another load flag LOAD_BYPASS_URL_CLASSIFIER is also introduced
for the same reason.
Differential Revision: https://phabricator.services.mozilla.com/D22110
--HG--
extra : moz-landing-system : lando
Disable the following tests, with 1536211 serving as the tracking bug:
- test_header_Server_Timing.js (1530871)
- test_trr.js (1532395)
- test_esni_dns_fetch.js (1530752)
Differential Revision: https://phabricator.services.mozilla.com/D23922
--HG--
extra : moz-landing-system : lando
When changing addr_info we didn't always update addr_info_gencnt, so when it the old AddrInfo was freed, even though we lock in nsDNSRecord::GetNextAddr, mIter would still point to the old AddrInfo.
Differential Revision: https://phabricator.services.mozilla.com/D23923
--HG--
extra : moz-landing-system : lando
nsHttpConnectionMgr::SpeculativeConnect may return early, without assigning ci to a RefPtr. In that case, we'd leak the nsHttpConnectionInfo. We need to have it in a RefPtr from the start to make sure we can't leak it.
Differential Revision: https://phabricator.services.mozilla.com/D23497
--HG--
extra : moz-landing-system : lando
Due to the p1 patch, the first time we get the result back from NS_ShouldSecureUpgrade is always asynchronously.
This means that the first http request could be completed slower than the http requests opened after the first one. There are some tests affected by this change, since these tests assume that http requests should be completed in the same order as these requests were created.
This patch fixes the tests by introducing a new method in nsIHttpProtocolHandler. This method returns a promise and makes sure the HSTS data is ready to read synchronously when the promise is resolved.
Once the HSTS is ready to read, the order of open/close channels will be the same.
Differential Revision: https://phabricator.services.mozilla.com/D21683
--HG--
extra : moz-landing-system : lando
1. Make nsHttpChannel::OnBeforeConnect async.
2. There are two ways to get the result from NS_ShouldSecureUpgrade. One is getting the result synchronously from the input reference and the other is via the provided callback.
Note that the callback is only used when the storage is not ready to read at startup.
Differential Revision: https://phabricator.services.mozilla.com/D20191
--HG--
extra : moz-landing-system : lando
Honza Bambas
Valentin Gosu
Christoph Kerschbaumer
dlee
Kershaw Chang
Sylvestre Ledru
Emilio Cobos Álvarez
Christian Holler
Gurzau Raul
Andrea Marchesini
Alex Gaynor
Mark Goodwin
Andreea Pavel
Edwin Gao
Rob Wu
Coroiu Cristina
Bogdan Tara