Pref callbacks registered via Preferences::Add*VarCache() are wrapped in a
ValueObserver -- which groups all callback requests that have the same prefname
and callback function -- and the ValueObserver is put into gObserverTable. This
is reasonable.
Observers registered via nsPrefBranch::Add{Weak,Strong}Observer() are wrapped
in a PrefCallback, and the PrefCallback is put into sRootBranch->mObservers.
This is also reasonable.
Pref callbacks registered via Preferences::RegisterCallback() are conceptually
similar to those registered via Preferences::Add*VarCache(). However, they are
implemented by using *both* of the above mechanisms: they are wrapped in a
ValueObserver which is put into gObserverTable, *and* that ValueObserver is then
wrapped in a PrefCallback which is put into sRootBranch->mObservers.
Using both mechanisms isn't necessary, so this patch removes the
PrefCallback/mObservers part. This makes Preferences::RegisterCallback() work
in much the same way as Preferences::Add*VarCache().
Specifically:
- Preferences::RegisterCallback() now calls PREF_RegisterCallback() instead of
Preferences::AddStrongObserver(). This makes it more similar to
RegisterPriorityCallback().
- Preferences::UnregisterCallback() now explicitly calls
PREF_UnregisterCallback() instead of Preferences::RemoveObserver (which
previously happened via ~ValueObserver() when the ValueObserver was removed
from gObserverTable and its refcount dropped to zerod).
MozReview-Commit-ID: 1tEQNeYrBUU
--HG--
extra : rebase_source : 431a42402397a172d562b81b8d46418503bb8dfe
It's no longer needed, now that legacy extensions aren't supported.
Pieces removed include the following.
- The "load-extension-default" observer notification.
- The code for reading defaults/preferences/*.js from extensions.
- The unit test for this stuff.
- A crash reporter annotation relating to very long prefs set by add-ons.
- All references to "ExtPrefDL".
MozReview-Commit-ID: KMBoYn3uZ3x
--HG--
extra : rebase_source : 4dc8ffd425c6cdf06806409090c4f9d04a64930b
The notable part of this change is Shutdown(). I've made it just null out
sPreferences, contrary to the old comment, which was strange for a couple of
reasons:
- ~Preferences() used to null out sPreference, which is backwards compared to
how this sort of thing normally works.
- In both the before and after cases, as far as I can tell,
Preferences::Shutdown() is called but ~Preferences() is never called;
something keeps the singleton Preferences instance alive until process
termination.
MozReview-Commit-ID: Ab0ui31rVcI
sRootBranch and sDefaultRootBranch have the same lifetime as sPreferences, so
this patch makes them non-static nsCOMPtr<> members of Preferences.
MozReview-Commit-ID: 1TLhh13ZpBI
--HG--
extra : rebase_source : 9419cd205b9a06f7ae82722a6732e3fc2722473b
This patch does the following.
- Reduces nesting and simplifies control flow by handling failure cases
earlier, and makes all three functions have identical structure.
- Avoids unnecessary temporary local variables, including |rv|.
- Removes low-value comments, including some misleading ones (e.g. "This
function will perform conversion...").
- PREF_GetCStringValue() previously did not check HasDefaultValue(), unlike the
other two. It now does.
- PREF_GetCStringValue() now calls SetIsVoid(true) at the start, so that
aValueOut will be Voided on all failure paths.
MozReview-Commit-ID: 2uCSv76Y8eu
--HG--
extra : rebase_source : 9ca9148ad0a5069bdd3e08aec0038216d27ea092
This patch converts it to use Gecko strings instead of C strings, which makes
it much nicer.
MozReview-Commit-ID: KtRp3vaXwN5
--HG--
extra : rebase_source : c6788cbed5c4b932eb5b4119c407aea538cb1799
This is needed for local developer builds to enable extended
telemetry recording by default. As a consequence, other subsystems
relying on this prefs will turn on (e.g. experiments, BHR, ...).
MozReview-Commit-ID: W3RarufCdY
--HG--
extra : rebase_source : 8690e969baad1b9191ea3fef9fb7dd6e41e00de7
In Unified Telemetry toolkit.telemetry.enabled controls whether we send base
collection data or extended collection. The difference is mostly in volume, not
in kind (though extended collection has a little stricter testing and monitoring
requirements).
Since the Preferences UI change in Firefox 56, users no longer have the ability
to change toolkit.telemetry.enabled. This is a good thing as for pre-release
users very few disabled extended collection, and even fewer release users
enabled it. This provides uniform collection based on channel which should
eventually net us some efficiencies.
Until then we need to align our use of the toolkit.telemetry.enabled pref with
the UI change that has already shipped. This is accomplished by locking t.t.e
to 'true' on pre-release channels and locking it to 'false' on everything else.
This doesn't apply to Android as it doesn't (yet) use Unified Telemetry. t.t.e
means something rather different there.
MozReview-Commit-ID: EOpWm8b0jWA
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
MozReview-Commit-ID: D3f7a1Vl1oE
--HG--
extra : rebase_source : e6e4b15d6d210cfd93686f96400281f02bd1d06b
In Unified Telemetry toolkit.telemetry.enabled controls whether we send base
collection data or extended collection. The difference is mostly in volume, not
in kind (though extended collection has a little stricter testing and monitoring
requirements).
Since the Preferences UI change in Firefox 56, users no longer have the ability
to change toolkit.telemetry.enabled. This is a good thing as for pre-release
users very few disabled extended collection, and even fewer release users
enabled it. This provides uniform collection based on channel which should
eventually net us some efficiencies.
Until then we need to align our use of the toolkit.telemetry.enabled pref with
the UI change that has already shipped. This is accomplished by locking t.t.e
to 'true' on pre-release channels and locking it to 'false' on everything else.
This doesn't apply to Android as it doesn't (yet) use Unified Telemetry. t.t.e
means something rather different there.
MozReview-Commit-ID: EOpWm8b0jWA
Because nsCString is nicer than UniqueFreePtr<char>.
The patch also streamlines pref_savePrefs(). And also changes StrEscape() to
always put quotations around the result, because that's needed in both call
sites.
MozReview-Commit-ID: HT7HZz4QiSN
--HG--
extra : rebase_source : 442bb6002e004803a9ecb637239a000f11ec5774
First, the patch removes the return values from PrefTypeFlags::Set*(). They
allow chained calls, but they're barely used and they just make the code harder
to read.
Second, the patch changes pref_SetValue() to not modify and return the pref
flags. It's clearer if the flags changing is done separately. This requires
passing pref_SetValue() the old type instead of the flags.
MozReview-Commit-ID: HZVS2TIlBIY
--HG--
extra : rebase_source : 6638244214cda15ceae5a1930659aed434d8261b
This makes it clear that the stored string values are never modified.
It requires some const_casts to free the strings, but that feels like an ok
trade-off.
MozReview-Commit-ID: JikBT3uwpfq
--HG--
extra : rebase_source : 1720969ba2c1ae245dff91a6d3a85d48fb669ced
There's not much use using |protected| in a |final| class.
MozReview-Commit-ID: IECyfNGZsL5
--HG--
extra : rebase_source : e734b360c18e5e040bea186d5aedf91137711861
It's always gHashTable, and all the other functions in this file work directly
on gHashTable rather than taking a parameter.
MozReview-Commit-ID: BDCEvcMlo8P
--HG--
extra : rebase_source : 8f136c100f2a4f7b2b34cfa884b8cc91c2d80e3a
It's unnecessarily general, because we only ever use
Preferences::DirtyCallback() as the callback.
And because it's no longer a callback, the patch renames DirtyCallback() as
HandleDirty().
MozReview-Commit-ID: Hl50dcxfVQq
--HG--
extra : rebase_source : 5807d2ed650466f85cd7325f2adccdc177ccb4d2
It's simple enough that having a separate function isn't helpful.
MozReview-Commit-ID: Ke9BIfp9yHU
--HG--
extra : rebase_source : 57aee451b8fd3450da4a604cefbf9fafda894b1c
Preferences.cpp has two functions named pref_DoCallback(). One of them has a
single use in the parser. This patch inlines that single use to remove the name
duplication.
MozReview-Commit-ID: HnyteQ0N5M1
--HG--
extra : rebase_source : 37a34f3fbe866eee71a7bf0bba07d9d67cc8c81d
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
This makes it clear that the stored string values are never modified.
It requires some const_casts to free the strings, but that feels like an ok
trade-off.
MozReview-Commit-ID: JikBT3uwpfq
--HG--
extra : rebase_source : e611e57de4f059275ae2908f7300065cf953461d
Because nsCString is nicer than UniqueFreePtr<char>.
The patch also streamlines pref_savePrefs(). And also changes StrEscape() to
always put quotations around the result, because that's needed in both call
sites.
MozReview-Commit-ID: HT7HZz4QiSN
--HG--
extra : rebase_source : f8d26a8c9f7ea911272113efc56744df639c5ccf
There's not much use using |protected| in a |final| class.
MozReview-Commit-ID: IECyfNGZsL5
--HG--
extra : rebase_source : bc9597ee45583e809f89f7e558cc325460390f98
It's always gHashTable, and all the other functions in this file work directly
on gHashTable rather than taking a parameter.
MozReview-Commit-ID: BDCEvcMlo8P
--HG--
extra : rebase_source : e5d10e42401136a9a82d665d9717cf71ecf7e4ae
First, the patch removes the return values from PrefTypeFlags::Set*(). They
allow chained calls, but they're barely used and they just make the code harder
to read.
Second, the patch changes pref_SetValue() to not modify and return the pref
flags. It's clearer if the flags changing is done separately. This requires
passing pref_SetValue() the old type instead of the flags.
MozReview-Commit-ID: HZVS2TIlBIY
--HG--
extra : rebase_source : 32950f00975f7d9df63fa0af1c36e82b58516245
It's unnecessarily general, because we only ever use
Preferences::DirtyCallback() as the callback.
And because it's no longer a callback, the patch renames DirtyCallback() as
HandleDirty().
MozReview-Commit-ID: Hl50dcxfVQq
--HG--
extra : rebase_source : f453d31215de3fdb0c5b6176becf2669e7ad55f1
It's simple enough that having a separate function isn't helpful.
MozReview-Commit-ID: Ke9BIfp9yHU
--HG--
extra : rebase_source : de1518544ddb28185635628c33d356ab07480c1c
Preferences.cpp has two functions named pref_DoCallback(). One of them has a
single use in the parser. This patch inlines that single use to remove the name
duplication.
MozReview-Commit-ID: HnyteQ0N5M1
--HG--
extra : rebase_source : 93f963d3ba445c1c3a482fa95dbab33e57dae188
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
--HG--
extra : rebase_source : 725ccf57943283a60ef8c9d654afe4515b4089f8
nsIPrefLocalizedString is meant to be a wrapper for nsISupportsString,
basically identical but with a different identifier. But it's not a
sub-interface of nsISupportsString. Instead it (almost) duplicates
nsISupportsString's internals.
Specifically, nsISupportsString has `attribute AString data`, resulting in
these C++ methods:
> NS_IMETHOD GetData(nsAString& aData)
> NS_IMETHOD SetData(const nsAString& aData)
nsIPrefLocalizedString has `attribute wstring data`, resulting in these C++
methods:
> NS_IMETHOD GetData(char16_t** aData)
> NS_IMETHOD SetData(const char16_t* aData)
Then we have nsPrefLocalizedString, the concrete subclass of
nsIPrefLocalizedString. It implements the AString methods via
NS_FORWARD_NSISUPPORTSSTRING, which forwards to mUnicodeString. It also
implements the wstring methods explicitly, and they just call the AString
methods. It's all a bit of a mess.
(Both interfaces also have `wstring toString()`. The forwarding works more
smoothly for that method.)
This patch changes nsIPrefLocalizedString so it is a trivial sub-interface of
nsISupportsString. This change eliminates the need for the wstring methods, so
the patch removes them as well. The net result is we have less code, and fewer
conversions between C strings and Gecko strings. The patch also merges the
nsISupportsString and nsIPrefLocalizedString cases in
nsPrefBranch::SetComplexValue(), because they are now identical. (The
nsISupportsString and nsIPrefLocalizedString cases in
nsPrefBranch::GetComplexValue() remain distinct; indeed, that's the whole
reason for having them as separate interfaces.)
Nicholas Nethercote
Sebastian Hengst
Alessio Placitelli
Chris H-C
Phil Ringnalda
Kris Maglione
Andrea Marchesini