(In reply to comment #57)
> At least some of the browser.safebrowsing.* prefs are already effectively
> toolkit prefs (url-classifier code checks the .enabled prefs). I don't think we
> need to worry about using the infoURL pref in toolkit, really, as long as
> there's suitable fallback (might want to remove the reportError...).
I would love to see any toolkit prefs living in browser/ moved to toolkit/. Linux distros are already having to do this with one url-classifier pref, so I'd love to see this fixed upstream on our end.
(In reply to comment #57) safebrowsing. * prefs are already effectively
> At least some of the browser.
> toolkit prefs (url-classifier code checks the .enabled prefs). I don't think we
> need to worry about using the infoURL pref in toolkit, really, as long as
> there's suitable fallback (might want to remove the reportError...).
I would love to see any toolkit prefs living in browser/ moved to toolkit/. Linux distros are already having to do this with one url-classifier pref, so I'd love to see this fixed upstream on our end.
http:// bazaar. launchpad. net/~mozillatea m/xulrunner/ xulrunner- 1.9.3.head/ annotate/ head%3A/ debian/ patches/ bzXXX_urlclassi fier_prefs_ in_toolkit. patch