Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
We want to ensure SafeBrowsing update request is never classified so we
can recover from a bad SafeBrowsing database.
SafeBrowsing lookup request is also critical because if it is blocked,
it means SafeBrowsing is out of function.
Differential Revision: https://phabricator.services.mozilla.com/D22113
--HG--
extra : moz-landing-system : lando
We want to ensure SafeBrowsing update request is never classified so we
can recover from a bad SafeBrowsing database.
SafeBrowsing lookup request is also critical because if it is blocked,
it means SafeBrowsing is out of function.
Differential Revision: https://phabricator.services.mozilla.com/D22113
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
This also changes a few MOZ_LOG() messages to use the error name
instead of the raw numerical nsresult value.
MozReview-Commit-ID: Jcngd0S9j2z
--HG--
extra : rebase_source : f6e974569d8845211e0b25dabef2c41dda2ca1b6
Refactor SafeBrowsing code so we can get the payload of gethash/update request when
updates fail.
MozReview-Commit-ID: NB1oacd185
--HG--
extra : rebase_source : 87e7ce94fd5cde9697946a00de90a821e5561168
Based on the telemetry that landed as part of bug 1336904, Safe Browsing
updates are failing too often: https://mzl.la/2qGkOPS
This should enable browsers on slower networks to reach the update
servers while still putting a reasonable bound on how long the update
thread can be blocked.
MozReview-Commit-ID: 6puVtpMT87K
--HG--
extra : rebase_source : 4b68bb6778b45068bb8a2d0dbdfddfe24a6b022f
These timeouts will ensure that we don't block the Safe Browsing update thread
for too long when we encounter slow or bad network conditions.
MozReview-Commit-ID: AJfR193cTf8
--HG--
extra : rebase_source : 5ae14f204ed88691fac4e9ba8c8202b8aa79b657
When starting up, SafeBrowsing.jsm will try to use DBService to add testing entries. Meanwhile,
listmanager will request StreamUpdater to download lists with a random initial delay.
The requests that listmanager issue to StreamUpdater will be queued up
if DBserve is busy and will be retried when StreamUpdater is notified that
the previous update is complete. However, in some edge cases,
the queued requests may not be processed until the next update request from listmanager.
For example, SafeBrowsing.jsm calls DBService.beginUpdate at t0 and the update is
complete at t1. If listmanager sends all requests via StreamUpdate between t0 and t1,
they will all be queued up and no further request can trigger the queued ones.
So in this patch I add a timer to re-trigger FetchNextRequest() in case StreamUpdater is not
notified the previous update is complete.
MozReview-Commit-ID: 3hHsS5N7WRI
--HG--
extra : rebase_source : 1c1ac7212626f1bf83b355dd27b1ddeae6df2e03
The probes keep track of V2 and V4 server response to update and getHash
request. The probes are keyed by provider
MozReview-Commit-ID: 3Uxjm6H77lE
--HG--
extra : rebase_source : 647523a24bad8334dbb34758954a5f5db0e9b96c
mTelemetryProvider might be empty if |CancelUpdate| is called during update.
In that scenario, the call flow will look like:
CancelUpdate -> UpdateError -> DownloadDone -> set mTelemetryProvider to empty ->
OnStartRequest -> record telemetry with empty key.
So in this patch, move mTelemetryProvider.Truncate() to OnStopRequest.
MozReview-Commit-ID: JDgNUqR4SKa
--HG--
extra : rebase_source : 42aa4c898f403a1189e67e355246ebed5aa4af44
nsTArray::AppendElement may cause memory reallocation if out of capacity.
In nsUrlClassifierStreamUpdater::FetchNextRequest(), we take the reference of
the first element of mPendingRequests and pass its member as reference to
DownloadUpdate(), where mPendingRequests.AppendElement will be called.
If the AppendElement in DownloadUpdate() causes realloc, the reference
becomes dangling.
The most efficient fix is to "move" the reference's (i.e. request)
member variables to DownloadUpdate() but I think in this case we can just
take the value from the array and pass it around with no given that the
array element contains simply a couple of strings and pointers.
MozReview-Commit-ID: KEZ5d3l3HoI
--HG--
extra : rebase_source : 4bf61a8a6f6bc57523dfbb7e5b0b40b7ce77a57a
Tim Huang
Tom Schuster
Mihai Alexandru Michis
Sylvestre Ledru
dlee
Gurzau Raul
Andrea Marchesini
Ciure Andrei
Dorel Luca
Jonathan Kingston
Christoph Kerschbaumer
Kris Maglione
arthur.iakab
Francois Marier
Brindusan Cristian
Thomas Nguyen
Wes Kocher
Bevis Tseng
Henry Chang
Tom Tromey