This makes the IPC messages a little bigger, but that's unavoidable.
MozReview-Commit-ID: 1oPz2Yjjd9y
--HG--
extra : rebase_source : 0cff8cf5b25f66b73f6864ce50c1e5f575026ec3
Preferences::SetPreference() is used when setting prefs in the content process
from dom::Pref values that are passed from the parent process. Currently we
use the high-level Set*InAnyProcess() methods to do this -- basically the same
code path as sets done via the API -- but this has several problems.
- It is subtly broken. If the content process already has a pref of type T with
a default value and then we get a SetPreference() call that tries to change
it to type U, it will erroneously fail. In practice this never(?) happens,
but it shows that things aren't arranged very well.
- SetPreference() also looks up the hashtable twice to get the same pref if
both a default value and a user value are present in the dom::Pref.
- This happens in content processes, while all other pref set operations occur
in the parent process. This is the main reason we have the Set*InAnyProcess()
functions.
In short, the setting of prefs via IPC is quite different to the setting of
prefs via other means -- because it happens in content processes, and it's more
of a clobber that can set both values at once -- and so should be handled
differently.
The solution is to make Preferences::SetPreference() use lower-level operations
to do the update. It now does the hash table lookup/add itself, and then calls
the new Pref::FromDomPref() method. That method then possibly calls the new
PrefValue::FromDomPrefValue() method for both kinds of value, and overwrites
them as necessary. SetValueFromDom() is no longer used and the patch removes it.
MozReview-Commit-ID: 2Rg8VMOc0Cl
--HG--
extra : rebase_source : 0eddc3a4b694a79af3e173aefa7758f8e2ae776b
And remove the type argument from PrefValue's constructor. This is needed
for the next patch.
MozReview-Commit-ID: Ls8hEU2uRQQ
--HG--
extra : rebase_source : 115828e219f6bbe04677ffc106068a662458481a
The nice thing about this is that the memory management of the strings
(moz_xstrdup() and free()) is now entirely within PrefValue.
MozReview-Commit-ID: KJjnURpmgfE
--HG--
extra : rebase_source : 39c058cddf5ebf9e19f9151f40fd507f6909a289
It's something of an obfuscation, and it forces together various bool values
that don't necessarily have to be together (and won't be together after future
refactorings).
The patch also reorders some function arguments for consistency: PrefType, then
PrefValueKind, then PrefValue.
MozReview-Commit-ID: KNY0Pxo0Nxf
--HG--
extra : rebase_source : d46d228c3b13549b2159757dcdaf9583cca828f7
Although it is a subclass of PLDHashEntryHdr, it's the main representation of a
pref, so the name should reflect that.
MozReview-Commit-ID: 5qJNQtjbFmH
--HG--
extra : rebase_source : f2bd77a57c4e2a48e24ead736f15856fbeb9f718
As is done in pref_SavePrefs().
The confusion here is because a Vector can fill 100% of its capacity, but a
hash table cannot go past 75% of its capacity.
MozReview-Commit-ID: 5JMbmtrxMGN
--HG--
extra : rebase_source : 5ce1ce9dd0259588a0df924c2b45c39497b1ce71
It represents a pref, so `Pref` is a better name. Within Preferences.cpp the
patch uses domPref/aDomPref to distinguish it from PrefHashEntry values.
MozReview-Commit-ID: HXTl0GX4BtO
--HG--
extra : rebase_source : c1e0726c55e7577720f669f0ed2dbc38627d853e
This factors out some common code from SetValue(), making it easier to read.
The patch also improves the comments in SetValue().
MozReview-Commit-ID: 60JnBlIS1q6
--HG--
extra : rebase_source : cc0e47eb556ab87549137777625856db12782702
Currently, you can create a pref that only has a user value, and then later
give it a default value with a different type. The entire pref is then recorded
as having this second type. This causes problems later when interpreting the
user value.
This patch makes SetValue() fail if it tries to set a default value whose type
differs from an existing user value. It also expands an existing test to cover
this case and some similar ones.
MozReview-Commit-ID: 89tvISQ7RNT
--HG--
extra : rebase_source : 6cf34da0ff24f5b90a88003445a4a7c88b1f3907
This requires adding an aPriority argument (defaulting to false) to
Preferences::RegisterCallback(). And RegisterVarCacheCallback() is no longer
necessary.
MozReview-Commit-ID: BMDk3HuaQVV
--HG--
extra : rebase_source : 17a61cfd9a82f24854162fc993223691041ea46d
In practice we always use the same functions for these purposes.
MozReview-Commit-ID: 4Be9pRhUeff
--HG--
extra : rebase_source : 3dfafd9479371d3a47ec263a66942ddbfbefdb46
This patch makes it a proper class, and moves existing functions into it.
MozReview-Commit-ID: 5pbT3ljq44R
--HG--
extra : rebase_source : ac7ba98f9d39b3cd6f71498a5e108cb6757034e0
And use new/delete for them. And make mDomain a unique pointer so it doesn't
need explicit deallocation.
MozReview-Commit-ID: E1jLccXaSwT
--HG--
extra : rebase_source : 5a64135d5471297ab98f8ec4557f66dac8b7eff9
Maybe<PrefType> is a better way of representing "no type".
MozReview-Commit-ID: Fnha5RxbNg4
--HG--
extra : rebase_source : 8e8322b0443305ab71acd6d98ea2607f626c5bce
This field isn't accessed outside PrefHashEntry.
MozReview-Commit-ID: IvwQe5UtjjJ
--HG--
extra : rebase_source : 5447d4e24bbf0d0637ee29377cc749b9b77b4e1e
We can move the setting into ReplaceValue() and ClearValue(), and then those
methods aren't needed any more.
The patch also removes some getter calls within PrefHashEntry by directly using
field names.
MozReview-Commit-ID: 42EAx1Kh9Et
--HG--
extra : rebase_source : 3393a80a9c5d2d7c660171cdda8d3914c35e96ea
There's an "XXX" comment suggesting a possible leak when string user values are
cleared. Turns out a lot of the time there won't be a leak, because the string
pointer isn't overwritten and ClearEntry() frees the string when the pref is
destroyed. However, if the user value is subsequently overwritten with a
different string, there will be a leak. Also, even in the non-leak case, we
currently hold onto the string for longer than necessary.
This patch introduces ClearUserValue() -- which frees the string when
appropriate -- and uses it in all the places where values are cleared.
MozReview-Commit-ID: ARuWUNzPTfy
--HG--
extra : rebase_source : 4567e37ba96ba3b4ae9b1972d887eeaed1257cb0
Specifically:
- rename it as NotifyCallbacks();
- remove the return value, because it is always NS_OK;
- some minor naming and declaration clean-ups.
MozReview-Commit-ID: GcH81owPLsp
--HG--
extra : rebase_source : 501a85f76bb823cc45dba8e4601584f5218b1a9e
It's a horrible method, but the horribleness was pre-existing. I hope to make
it nicer in a follow-up bug.
MozReview-Commit-ID: 3tMTEeBNVax
--HG--
extra : rebase_source : b21d80ed6468b7c22689df64c1ae1bdda49a2a06
This moves part of pref_savePrefs() into PrefHashEntry.
This requires moving StrEscape() higher up to avoid a forward declaration.
Note that clang-format insists on indenting an unrelated comment, I don't know
why.
MozReview-Commit-ID: 7gww3r7t9y4
--HG--
extra : rebase_source : 63f19bb2c556cc806cc6ce43e70ac6c95e6d67bc
And invert its sense, renaming as Equals(), because that is easier to think
about.
The patch also reorders some conditions so that
HasDefaultValue()/HasUserValue() is tested before Equals(). This isn't strictly
necessary, but it reads better.
MozReview-Commit-ID: JeGrevDwqKz
--HG--
extra : rebase_source : 575758e11d7e66226fe196f92f2dd355b1444d1d
This requires adding a constructor, which is used in a placement new.
MozReview-Commit-ID: 3v6843D5DMu
--HG--
extra : rebase_source : 780902ae8e761bdf1141f24bf5594ce910ea32b4
And rename it as ToSetting(). This requires also moving
AssignPrefValueToDomPrefValue into PrefHashEntry.
MozReview-Commit-ID: 8ntNZJt9rhv
--HG--
extra : rebase_source : 5dd5a2c570b2ceefb506b4051c414b06d27a95f2
This patch:
- partially inlines GetPrefValueFromEntry() at its two call sites, to avoid
repeating the kind check;
- renames it as AssignPrefValueToDomPrefValue().
MozReview-Commit-ID: BUBk3ML6h5O
--HG--
extra : rebase_source : eb12adf4af2ee05356af6b2b4f346aa3425ff438
PrefTypeFlags is a class with a lot of smarts (i.e. methods). PrefHashEntry is
a class with little smarts. This is silly, because PrefTypeFlags is essentially
an internal implementation detail of PrefHashEntry.
This patch merges PrefTypeFlags into PrefHashEntry, so that PrefHashEntry has
all the smarts. This means lots of `pref->mPrefFlags.Foo()` calls become
`pref->Foo()`.
The patch also changes the representation of the type and flags within
PrefHashEntry to use bitfields, which avoids the need for a Flags type and is
much simpler than the old approach.
MozReview-Commit-ID: 4Yt9OtBzh9e
--HG--
extra : rebase_source : 18fc01217aeaee7057b3d9a54b18cae45be5538f
