Instead of modifying SavePrefFile to do off-main-thread writing for
the non-nullptr case, I chose to create a new method dedicated to
writing to the non-default preference file for backing up. This
method will always use off-main-thread writing, unless the preference
service is configured to not allow that.
In either case, it'll return a Promise that resolves when the backup
file has been written.
This also fixes a bug where calling SavePrefFile with some nsIFile
wouldn't necessarily write to that file if there was a prior write
operation still being processed.
Differential Revision: https://phabricator.services.mozilla.com/D203832
If `IsPreferenceSanitized(char*)` is called, it will call pref_Lookup
which is not thread-safe. StaticPrefs use that function to check
pref sanitization.
Prefs are sanitized if they are a no-default-value string-type preference
_or_ their name is in sRestrictFromWebContentProcesses. The first check
is intended to catch prefs set dynamically, ones we don't know about
and may want to sanitize. But Static Prefs we know all about. So we can
omit that check for them. We only (in theory) need to check them against
the blocklist.
In practice: no Static Prefs are sanitized. If they were (and they were
not mirror-never prefs), it would have exposed the bug that makes content
processes crash on startup, because we would crash during initialization.
That initialization happens while reading the prefs from the Shared Map -
sanitized prefs can't be in the shared map. So we can take a shortcut and
instead of building in support for Static Prefs to be initialized from
the HashMap instead of the shared map (perhaps as simple as
s/GetSharedPrefValue/GetPrefValue), we can just crash if someone adds a
Static Pref to the list of things to be sanitized.
Differential Revision: https://phabricator.services.mozilla.com/D189968
Bug 1444275 introduced an assertion on the parent process to check that
the value of toolkit.telemetry.enabled is the expected one.
However, this expected value could be different from the one set and
locked e.g. in some forks. Therefore, the assertion prevented debug
builds from working in these cases.
Differential Revision: https://phabricator.services.mozilla.com/D195080
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
The services.* preferences branch gets sanitizer by default. Exceptions
need to be added in the ShouldSanitizePreference method.
services.settings.loglevel got added in bug 1840851.
services.settings.preview_enabled got added in bug 1780403.
Differential Revision: https://phabricator.services.mozilla.com/D183442
In mozilla-central before this patch, we had a boilerplate
NS_ENSURE_SUCCESS(rv, rv) after our call to GetObserverService()
This expression *does not actually test whether GetObserverService() succeeded*
though, since GetObserverService doesn't touch rv! When GetObserverService()
fails, it just returns nullptr. So we should be testing it for success with a
null-check.
In fact, we did *used to* test for success with a null-check, but that was
replaced by this ineffective NS_ENSURE_SUCCESS by accident in Bug 1276488, as
part of a large patch that was geared at adding diagnostics.
So: let's just restore the null-check. It's unlikely to be tripped, since
GetObserverService only returns nullptr at xpcom shutdown time (and this code
runs at startup); but explicitly handling that by returning a failure code
seems to be the right thing to do. And more importantly, the NS_ENSURE_SUCCESS
can be made to misfire if we happen to have a stray error code from some
earlier call remaining in 'rv'.
Differential Revision: https://phabricator.services.mozilla.com/D174544
Preferences from /etc/firefox/defaults/pref overwrites preferences set in omni.jar
and firefox/defaults/pref. The code was used for flatpak and snap only, but it could
be used also for regular Linux builds.
Differential Revision: https://phabricator.services.mozilla.com/D168799
Preferences from /etc/firefox/defaults/pref overwrites preferences set in omni.jar
and firefox/defaults/pref. The code was used for flatpak and snap only, but it could
be used also for regular Linux builds.
Differential Revision: https://phabricator.services.mozilla.com/D168799
1. Ship the Sanitization (currently on in Nightly
but without crashing) to the trains
2. Enabling crashing in Nightly
#1 will start omitting the preference values in
Content Processes. An affected user will have
their browser behave differently - it will be as
if the preference has no value. So for e.g. the
font preferences, their font customizations will
be gone. If they file a bug about this happening
and an engineer connects the problem to pref
sanitization we could debug the issue and maybe
understand it.
#2 will mean that an affected user (of which
there are currently none we think) will have a
content process crash when they access a
forbidden preference. The crash reason will
contain the name of the preference, and the
stack which would help us better understand
why we crashed.
Differential Revision: https://phabricator.services.mozilla.com/D167287
Dave Townsend