1451698 - formatURLPref: Couldn't get pref: browser.safebrowsing.provider.mozcn.updateURL

Status: NEW

(Toolkit :: Safe Browsing, defect, P3)

Description

[:Gijs (he/him)]

This bug was automatically filed from Sentry: https://sentry.prod.mozaws.net/operations/nightly-js-errors/issues/3492682/

formatURLPref: Couldn't get pref: browser.safebrowsing.provider.mozcn.updateURL
    at uf_formatURLPref(jar:file:///D:/users/<blah>/AppData/Local/Firefox%20Nightly/omni.ja!/components/nsURLFormatter.js:123:7)
    at updateProviderURLs/<(resource://gre/modules/SafeBrowsing.jsm:345:23)
    at forEach(self-hosted:268:13)
    at updateProviderURLs(resource://gre/modules/SafeBrowsing.jsm:341:5)
    at readPrefs(resource://gre/modules/SafeBrowsing.jsm:292:5)
    at init(resource://gre/modules/SafeBrowsing.jsm:67:5)
    at _scheduleStartupIdleTasks/<(jar:file:///D:/users/<blah>/AppData/Local/Firefox%20Nightly/browser/omni.ja!/components/nsBrowserGlue.js:1171:7)


This seems to be caused by a "mozcn" safebrowsing provider. Do we ship this with the Mozilla China build, or something? Maybe it should define the updateURL, or maybe we should stop doing it, or maybe we should avoid reporting errors if a lack of updateURL is expected. François or Hector, do you know the details here?

Comment 1

[Mike Kaply [:mkaply]]

This appears to be shipped as part of the [e-mail] extension. In particular, extensions/cpmanager/modules/CNSafeBrowsingRegister.jsm (If I'm reading the code correctly).

Comment 2

[François Marier [:francois]]

Yes, it's part of the Mozilla China builds. I'm not sure why it's not definining the updateURL pref while still defining some of the other ones.

Maybe that Safe Browsing provider is no longer in use by these builds but not all of the prefs have been cleaned up?

I suppose we could add a try/catch around these lines: https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/toolkit/components/url-classifier/SafeBrowsing.jsm#345-348

Comment 3

[Hector Zhao [:hectorz]]

(In reply to :Gijs (he/him) from comment #0)
> This bug was automatically filed from Sentry:
> https://sentry.prod.mozaws.net/operations/nightly-js-errors/issues/3492682/
> 
> formatURLPref: Couldn't get pref:
> browser.safebrowsing.provider.mozcn.updateURL
> 
> 
> This seems to be caused by a "mozcn" safebrowsing provider. Do we ship this
> with the Mozilla China build, or something? Maybe it should define the
> updateURL, or maybe we should stop doing it, or maybe we should avoid
> reporting errors if a lack of updateURL is expected. François or Hector, do
> you know the details here?

(In reply to Mike Kaply [:mkaply] from comment #1)
> This appears to be shipped as part of the [e-mail]
> extension. In particular,
> extensions/cpmanager/modules/CNSafeBrowsingRegister.jsm (If I'm reading the
> code correctly).

As :mkaply pointed out, two new safe browsing providers, baidu and mozcn, are added by us at Beijing office using the [e-mail].

(In reply to François Marier [:francois] from comment #2)
> Yes, it's part of the Mozilla China builds. I'm not sure why it's not
> definining the updateURL pref while still defining some of the other ones.

We set the browser.safebrowsing.provider.${providerSlug}.(advisoryName|advisoryURL|gethashURL|lists|reportMalwareMistakeURL|reportPhishMistakeURL|updateURL) prefs on default branch to register these two providers. And Firefox will set browser.safebrowsing.provider.${providerSlug}.(lastupdatetime|nextupdatetime)

If for any reason, our extension got disabled or uninstalled, the remaining (lastupdatetime|nextupdatetime) prefs will make Firefox try to initialize the no longer defined providers[1].

> 
> Maybe that Safe Browsing provider is no longer in use by these builds but
> not all of the prefs have been cleaned up?
> 
> I suppose we could add a try/catch around these lines:
> https://searchfox.org/mozilla-central/rev/
> f860c2bf00576959b07e2d9619c7b5088b0005be/toolkit/components/url-classifier/
> SafeBrowsing.jsm#345-348

(lastupdatetime|nextupdatetime) was skipped for `readPrefs` in bug 1296751. Maybe we'd better exclude them here too.

[1]: https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/toolkit/components/url-classifier/SafeBrowsing.jsm#316-327