After this patch landed, we will have 3 cases:
1. For providers are not "test", for example, google, google4, mozilla ... etc
backoff CANNOT be disabled.
2. For "test" provider, if preference "browser.safebrowsing.provider.test.disableBackoff" is ON
backoff is disabled.
3. For "test" provider, if preference "browser.safebrowsing.provider.test.disableBackoff" is Off
backoff is NOT disabled.
So if your testcase will use listmanager or hashcompleter, you should try to use "test" provider
if possible, otherwise testcase may encounter intermittent failure due to backoff.
MozReview-Commit-ID: 3BDxs0ARyQM
After this patch landed, we will have 3 cases:
1. For providers are not "test", for example, google, google4, mozilla ... etc
backoff CANNOT be disabled.
2. For "test" provider, if preference "browser.safebrowsing.provider.test.disableBackoff" is ON
backoff is disabled.
3. For "test" provider, if preference "browser.safebrowsing.provider.test.disableBackoff" is Off
backoff is NOT disabled.
So if your testcase will use listmanager or hashcompleter, you should try to use "test" provider
if possible, otherwise testcase may encounter intermittent failure due to backoff.
MozReview-Commit-ID: 3BDxs0ARyQM
This patch adds a |ForceUpdates| API in listmanager so when we change Safe Browsing tables,
we can use this API to force an update to ensure new tables are downloaded immediately.
If the update fails for any reason (Server is down for example), then the new tables will have
to wait until next update time.
MozReview-Commit-ID: 3Zh1pU8XaYo
This patch adds a |ForceUpdates| API in listmanager so when we change Safe Browsing tables,
we can use this API to force an update to ensure new tables are downloaded immediately.
If the update fails for any reason (Server is down for example), then the new tables will have
to wait until next update time.
MozReview-Commit-ID: 3Zh1pU8XaYo
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
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
These methods do not appear to be used.
When JSM global sharing is enabled, these methods contaminate the
global Function.prototype, which breaks Marionette object
serialization.
MozReview-Commit-ID: CAfJ2FCkhlK
