Safebrowsing testcase will close and then re-open database to simulate firefox restart.
This bug happened when DB service already has a previously cached completion result and then
re-open database. In this scenario, if testcase triggers another the same completion request,
we won't cache it because we thought we have it already (See nsUrlClassifierDBServiceWorker::CacheCompletion).
This causes a testcase assertion when testcase expects the completion
result should be stored in LookupCache.
MozReview-Commit-ID: 8o57jHv92OH
--HG--
extra : rebase_source : 90861060437d6cef860b85dd669d76e74ceec660
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
MozReview-Commit-ID: D3f7a1Vl1oE
--HG--
extra : rebase_source : e6e4b15d6d210cfd93686f96400281f02bd1d06b
We suspect nsTArray Compact may cause a crash issue during SafeBrowsing
update. Temporarily remove it from NIGHTLY build, if crash still shows
at NIGHTLY build, we will restore it back.
MozReview-Commit-ID: 2wjbMykEbJ8
--HG--
extra : rebase_source : 1be0d12e9d1de7f249c509cfa016bb26242cbdc7
When about:url-classifier ask cache information by using |GetCacheInfo| API, this API
will send a SYNC request to off-main thread. If NSS module is not initialized then off-main thread
will send init request to main thread, and this causes a deadlock.
This patch change |GetCacheInfo| API to asynchronous so main thread will not be
blocked.
MozReview-Commit-ID: 3y2hOjCoRUj
--HG--
extra : rebase_source : 4d1ec1b7fd960cdf90bca577879b41fbbc2a4e17
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
In order to optionally report the full hash back to Google, we need to keep it
around in the callback. While a prefix is not the same as a full hash (multiple
full hashes can map to the same prefix), in this case, the callback will only be
called when the full hash matches.
MozReview-Commit-ID: F4WSLZpYrXB
--HG--
extra : rebase_source : da3b16b00729d0aa6ff1765a135b751fcf44c012
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: KXJM13VRTB7
--HG--
extra : rebase_source : 3e50b1b3f23248d668d15310554559c39ff792f7
extra : source : 74f5e05877d50a79ec1e5330c227d2ce576a2d90
With JSM global sharing, the object returned by Cu.import() is a
NonSyntacticVariablesObject, rather than a global. Various code tries
to use properties from a JSM global via an import.
Cu.importGlobalProperties can also be used in some places.
MozReview-Commit-ID: HudCXO2GKN0
--HG--
extra : rebase_source : 6b5fa6f5509397504cb461a761f6cc2399f18c40
The issue occurs when nsITimer is fired earlier than the backoff time. In that
case, the update doesn't proceed and we never make another attempt because the
backoff update timer was oneshot.
We fix the issue in two ways:
- Add a tolerance of 1 second in case the timer fires too early.
- Set another oneshot timer whenever we are prevented from updating due to
backoff.
MozReview-Commit-ID: E2ogNRsHJVK
--HG--
extra : rebase_source : c81fa77934f6c39e1c5d07b19785a01546e02542
The issue occurs when nsITimer is fired earlier than the backoff time. In that
case, the update doesn't proceed and we never make another attempt because the
backoff update timer was oneshot.
We fix the issue in two ways:
- Add a tolerance of 1 second in case the timer fires too early.
- Set another oneshot timer whenever we are prevented from updating due to
backoff.
MozReview-Commit-ID: E2ogNRsHJVK
--HG--
extra : rebase_source : 17aa70d8583cc84e28e57410de66eaac63bd18bb
This fixes usages of `Find`, `RFind` and the equality operator that kind of
work right now but will break with the proper type checking of a templatized
version of the string classes.
For `Find` and `RFind` it appears that `nsCString::(R)Find("foo", 0)` calls
were being coerced to the `Find(char*, bool, int, int)` versions. The intent was
probably to just start searching from position zero.
For the equality operator, the type of nullptr is nullptr_t rather than
char(16_t)* so we'd need to add an operator overload that takes nullptr_t. In
this case just using `IsVoid` is probably more appropriate.
--HG--
extra : rebase_source : 50f78519084012ca669da0a211c489520c11d6b6
Version 4 of the Google Safe Browsing server will return a 404 if any of the
application reputation lists are requested on Android. As a result, we should
avoid these threat types from being sent along with ANDROID_PLATFORM.
MozReview-Commit-ID: 6TUBVxe455y
--HG--
extra : rebase_source : dee095c008f4d328f359c66d20f0cc2dfcd109f3
extra : source : 5d6338807c6b21b7672236cac01b13bd75155225
