Bug 40788: Deal with some remote settings of Firefox

Merge Info

Related Issues

• #40788 (closed)

Backport Timeline

• Immediate - patchsets for critical bug fixes or other major blocker (e.g. fixes for a 0-day exploit) OR patchsets with trivial changes which do not need testing (e.g. fixes for typos or fixes easily verified in a local developer build)
• Next Minor Stable Release - patchset that needs to be verified in nightly before backport
• Eventually - patchset that needs to be verified in alpha before backport
• No Backport - patchset for the next major stable

Not sure: some are prefs, so safe enough to backport.

Another thing is disabling some existing code, should be safe enough to backport, but I am waiting to see also Moz's response. If they say it's okay, and accept the patch, we could backport it.

Upstream Merging

• Merge to base-browser - typically for !fixups to patches in the base-browser branch, though sometimes new patches as well
  • NOTE: if your changeset includes patches to both base-browser and tor-browser please please make separate merge requests for each part

Issue Tracking

• Link resolved issues with appropriate Release Prep issue for changelog generation

Change Description

Fixes the 2 of the 3 problems found in #40788 (closed):

• AS related settings. Maybe not necessary after !436 (merged), but we usually add preferences to be sure anyway
• Do not initialize nsIURLQueryStrippingListService if it isn't enabled, and avoid initializing its remote settings.

For the latter, I'm not sure whether we should have a commit on its own, since I've opened also a Bug.

Also, I didn't get surprises on the console. And I expected so, since it's disabled, just like many other Moz's stuff to enhance privacy.

However, getting some information from Moz people could be very useful, too.

Doesn't fix the hijack-list, yet. We normally opt-out of such protections, because they involve more dialog with Moz services. But this one could be done offline, and maybe actually improve the UX. Disabling it seems like a free-spech absolutist move, in a certain sense.

I think we could deal with it in #40569 (and leave #40788 (closed) open, since we don't resolve all the problems? Or close it anyway?)