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
They are guaranteed to be zeroed already by PLDHashTable.
MozReview-Commit-ID: LBeGa9ABYc3
--HG--
extra : rebase_source : f767d0d20cfb1c187496be20fff4cce43c768ccd
Because they are the pref's values, not the pref itself.
MozReview-Commit-ID: 1N4Fh2TF8lL
--HG--
extra : rebase_source : 5645a0e5897fc825e6bbc6da2c6d40fb852a9efb
It's the user value that's sticky, not the default value. Though we typically
talk about the entire pref being sticky, so that's what this patch does.
MozReview-Commit-ID: 8THuRCTZ7uw
--HG--
extra : rebase_source : 8164f71065bcae1376c3e2bf241593c62c90b702
This matches the corresponding string "sticky_pref".
MozReview-Commit-ID: 8bqM5x8bIoG
--HG--
extra : rebase_source : 20b5b8b8df8b936a22849766552d11f659ffc84b
So that "default value" and "user value" are used consistently.
MozReview-Commit-ID: Hmfct8STu33
--HG--
extra : rebase_source : 3f27992630e6e834ce470693a15d8f6b99706cfe
This makes it like the VarCache functions for int, uint, atomic unit, and float.
MozReview-Commit-ID: 4CRuvAjqGCj
--HG--
extra : rebase_source : 5780456f1f0cf18f98ab3b42efcaec514324a171
Because it holds 8-bit strings, which only need 1 byte alignment.
For the profile on my Linux box, in every process this reduces the size of the
arena by 1 chunk, from 120 KiB to 112 KiB.
MozReview-Commit-ID: 8ozrLIq5ZZ4
--HG--
extra : rebase_source : 1f7d337875d5f554772bec6395e7f4241900a26c
