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
High resolution, high framerate was disabled by default on old AMD cards on the provisio that it was bad. But this assumes that the CPU decoder could do it better.
This assumption appears fragile at best, as CPU with those old adapter are likely to be old and underpower to start with.
Chrome doesn't appear to restrict use of those cards to a given resolution.
So we disable this restriction, while making it user configurable.
MozReview-Commit-ID: HhADHNR0FdJ
--HG--
extra : rebase_source : ece39cd9b84c6e372d1002ee12e72523cee3d04d
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
Before bug 1367813, the code in test_stickyprefs.js, using
readUserPrefs, would end up changing the file under which the
preferences service would save user prefs, making xpcshell
possibly overwrite the test data files at the end of the test run.
A hack was put in place to avoid this, that is not required anymore.
--HG--
extra : rebase_source : 6a4b1442c0d1593322226ad162c421df4f9c7f87
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
- Ensure ovr_GetSessionStatus is polled even when a VR presentation
is not active.
- When we fail to initialize an Oculus Session or detect VR hardware,
immediately unload the Oculus Library as we can't poll for ShouldQuit
without a valid Oculus session.
- When we poll ovr_GetSessionStatus, we are now updating the mounted state
in VRDisplayInfo::mIsMounted.
- Added prefs to control enumeration throttling and timeout to release
VR hardware when inactive.
- Some refactoring to make frame loop more understandable and less
brittle.
- When throttling enumeration, we ensure that all other VR apis
also throttle enumeration so that they don't pick up the same device
during throttling.
- Some long functions in VRManager have been broken up and
had their inner-workings documented in more detail.
MozReview-Commit-ID: CEYwwQ9mYd0
--HG--
extra : rebase_source : b82cd9f200e6311528d4bed469d1b8044e9fc7f2
extra : amend_source : e74f56f5ec95641fd478deb71d6c7ba5d2cba7b1
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
This removes from all.js some dom, browser, autocomplete, ui, and other prefs
that are no longer accessed in our code.
MozReview-Commit-ID: JGoBZ2GUbPD
--HG--
extra : rebase_source : cc87f28ca547ac5568a6df0dd5c3561712dc149d
This removes prefs for printing that are only declared in all.js but not accessed
elsewhere. Also correct the name of "print.print_in_color".
MozReview-Commit-ID: GrHNUjCiijA
--HG--
extra : rebase_source : 2d778dd6e517c10b569ff98af8da1ed9b80308e0
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
This commit removes the `layers.omtp.force-sync` preference and replaces
it with a preprocessor define that is commented out. This commit also
changes the behavior of force-sync so that it also does synchronization
with CompositorBridgeChild like normal OMTP. This simplifies the code
and makes using a preprocessor define easier.
MozReview-Commit-ID: 6RfuFTFBdMh
--HG--
extra : rebase_source : 0778a3087324b9e87f44587efbb49c71edf47f23
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
This patch renames it as gInstallingCallback, adds a comment, and reduces the
scope of the AUTO_INSTALLING_CALLBACK() objects to the minimum.
MozReview-Commit-ID: EGfnBPVFtmw
--HG--
extra : rebase_source : 9feafbb4c92c6b9dbe37466fefb777a8638b1c6e
This splits the measurements into several buckets, like so:
> 718,528 B (00.40%) -- preferences
> ├──262,176 B (00.14%) ── hash-table
> ├──181,952 B (00.10%) ── callbacks
> ├──122,880 B (00.07%) ── pref-name-arena
> ├───91,872 B (00.05%) ── root-branches
> ├───38,296 B (00.02%) ── string-values
> ├───21,272 B (00.01%) ── cache-data
> └───────80 B (00.00%) ── misc
The patch also measures some things that were previously overlooked.
- String pref values. (The old code had a comment that incorrectly claimed they
were allocated out of an arena.)
- The PrefCallback objects pointed to by entries in nsPrefBranch::mObservers.
And it makes the code more like typical reporters.
- It removes the "AndOtherStuff" from Preferences' measuring method, and
measuring those global structures in
PreferenceServiceReporter::CollectReports().
- It adds `const` where appropriate.
MozReview-Commit-ID: dyNg7ldQdh
This patch also adds some Set*InAnyProcess() methods, and makes nsPrefBranch a
friend of Preferences so it can call those methods.
And it moves the thin Set*() wrapper functions to Preferences.h, alongside
SetUint().
MozReview-Commit-ID: 88HhmcTFZNc
--HG--
extra : rebase_source : 88a854d52afce86d93008a6e1a4b5f32bcf24a1a
This will allow other functions to be moved into Preferences and be marked as
`private` in subsequent patches.
The patch also renames SetPrefValue() as SetValueFromDom(), because that's a
clearer name.
MozReview-Commit-ID: CB1xmPSmac6
--HG--
extra : rebase_source : 0d597a800f2295c04af26d5abaac4aea0e0d3373
It's a `final` class, so there's no need for `protected`.
MozReview-Commit-ID: 7n4DLpXo0el
--HG--
extra : rebase_source : b2d3eb9cf0e912689efa29d2255cc018fd8a7c64
This is unused for now, but will be necessary for nsPrefBranch::Set*() to call
into Preferences::Set*().
The patch also renames some arguments from aPref to aPrefName, because that's a
better name.
MozReview-Commit-ID: 2OPB7CHOgpw
--HG--
extra : rebase_source : 232b7be3c33d185f13ce86d91feea3b55069a4e6
This is nicer than a bool for tracking the Default vs. User distinction, and it
replaces the Preferences.cpp-only WhichValue type.
MozReview-Commit-ID: 8CrdDN2vBJQ
--HG--
extra : rebase_source : 0d49148c73e5aeb0a355a6d4189232c89295d2a7
This also changes URIUtils.cpp:DeserializeURI() to use the mutator to instantiate new URIs, instead of using their default constructor.
MozReview-Commit-ID: JQOvIquuQAP
--HG--
extra : rebase_source : e146624c5ae423f7f69a738aaaafaa55dd0940d9
Given that we only support macOS >= 10.9 nowadays, we don't need
to consider fallbacks on old systems anymore.
Removing LiHei Pro & LiSong Pro because they are old.
Removing STSong & STHeiti because they are simply old font names aliased to new Songti/Heiti SC.
MozReview-Commit-ID: BNYBjXCpQOr
--HG--
extra : rebase_source : 4c19607d183ac4033c8bdc05bd05b92c906a5e9d
libpref only allows pref modifications in the parent process. This patch
tightens up the checking, which is a bit inconsistent.
- It removes ENSURE_MAIN_PROCESS_WITH_WARNING, which does NS_WARNING on
failure, and replaces its uses with ENSURE_MAIN_PROCESS, which does NS_ERROR
on failure. This required adding an XRE_IsParentProcess() check to one place
in editor/.
- It converts XRE_IsContentProcess() tests to !XRE_IsParentProcess(), because
we now have multiple kinds of non-parent process.
- It uses ENSURE_MAIN_PROCESS to replace other checking code in a few places.
- It improves a comment in HandleDirty().
MozReview-Commit-ID: D8znQWH7ery
--HG--
extra : rebase_source : ea0fc095b31525bde82a1be217923512d030b76d
InitStaticMembers() is the hottest function within libpref, because it is
called from all the getters and setters. This patch tweaks it so the common
case is handled with a single comparison, instead of two. This is valid because
sPreferences is nulled at the same time that sShutdown is set.
The patch also tweaks some other conditions to take advantage of this fact.
MozReview-Commit-ID: C74fLWOw7bE
They both have two callsites, but in one of those they appear together, where
much of the code can be replaced with a ClearAndPrepareForLength() call.
MozReview-Commit-ID: 1A771gsHWan
--HG--
extra : rebase_source : c6f26b9a825155c7b7c885540cf9f34f8b8eace7
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : b885ee784704819e181430200af5ef762e269d14
Bug 1108587 seems to suggest that the grace period for nsTerminator is
too short for ASAN builds, which take much longer to shutdown. This
patch changes the grace period from 1 minute to 3 minutes, hoping that
this will be sufficient. Somewhere along the way, we also extend the
duration of AsyncShutdown, because that's the simplest way to do both
at once.
MozReview-Commit-ID: 28eWO5m6Wh3
--HG--
extra : rebase_source : eae9db952d5395f986781f3cbd23507b715fa8c9
The various getters and setters are in a confusing order. This patch puts them
in a more sensible order. It also streamlines the comments, which were
generally low-value and in some cases incorrect.
MozReview-Commit-ID: 3ngzZDSt0JI
--HG--
extra : rebase_source : 8a5a66f65621889483d2df9f4487194172f70804
widget.allow-client-side-decoration is no longer used, titlebar rendering is controled by browser.tabs.drawInTitlebar only.
MozReview-Commit-ID: LHdBio4Gfry
--HG--
extra : rebase_source : 7cdd788978d0209702d5212ac7be4daa1c616393
AutoplayPolicy is used to manage autoplay logic for all kinds of media,
including MediaElement, Web Audio and Web Speech.
MozReview-Commit-ID: R1TxMkarIw
--HG--
extra : rebase_source : 8c608a1d12c8e205391a91f22e1532bc4f2c8f16
This class isn't being used right now, and MozURL is a much better alternative if interaction with rust URLs is required.
MozReview-Commit-ID: ADdYRrrTnr6
--HG--
extra : rebase_source : b36aa26c20e7daaadab1f3360bab0ed4681eb7f8
There's no good reason why these can't be code constants.
Especially given that, due to a bug, changes to the
"idle_queue.{min,long}_period" constants were not being passed onto the C++
code!
Here's why: those two prefs were specified as integers in all.js. But we used
AddFloatVarCache() to set up the reading of those prefs. libpref fakes floats
by storing them as strings and then converting them to floats when they are
read.
Which means that AddFloatVarCache() used to fail to get the value from all.js
-- because there's a type mismatch, int vs. string -- and instead use the
fallback default. That value is the same as the one in all.js, which is lucky.
But if someone changed the value in about:config to 100 (an integer), a similar
failure would have occured and the value used by the C++ code wouldn't be
updated!
Also note that idle_queue.max_timer_thread_bound did not have a value in
all.js.
What a mess!
--HG--
extra : rebase_source : 86f8fa905163803eb95007609c029e18c2c4f586
There's no good reason why these should't just be constants. The patch also
appends "MiB" to some of the C++ values to make their meaning clearer.
This patch fixes one outright bug, and one inconsistency.
The bug is due to a prefname mismatch:
- ContentPrefs.cpp and AvailableMemoryTracker.cpp use
"memory.low_virtual_mem_threshold_mb".
- all.js uses "memory.low_virtual_memory_threshold_mb".
Which means that "memory.low_virtual_memory_threshold_mb" showed up in
about:config, but if you changed it nothing would happen because the callback
listened for changes to to "memory.low_virtual_mem_threshold_mb"!
Now for the inconsistency. The above means we actually use a value of 256 for
the virtual memory threshold, even though all.js says 128. But we *do* use a
value of 128 for the commit space threshold, because that's what all.js says
and that prefname is used correctly everywhere. The patch changes the commit
space threshold to 256 for consistency with the virtual memory threshold.
What a mess!
--HG--
extra : rebase_source : d3842c732efa9ab0e90eeb6a4f341aeb289589ed
This was originally added for b2g, where the pref had a different value.
Bug 1398033 enabled it everywhere.
--HG--
extra : rebase_source : c8bb03190cd00d25e6c2ec62a99ed8e911e08197
libpref has callbacks. You can register a callback function against a
particular pref (or pref prefix), and it'll be called when any matching pref
changes.
This is implemented in two layers. The lower layer is the list of CallbackNode
objects, pointed to by gFirstCallback.
The upper layer involves gObserverTable, which is a hash table of ValueObserver
objects. It is used for callbacks registered via
Preferences::RegisterCallback() and Preferences::Add*VarCache(), but not for
observers registered with Preferences::Add{Weak,Strong}Observer(). If multiple
callbacks with identical prefnames, callback functions and MatchKinds occur,
they are commoned up into a single ValueObserver, which is then wrapped by a
single CallbackNode. (The callbacks within a single ValueObserver can have
different void* aClosure args; ValueObserver keeps those in an nsTArray.)
Note also that gObserverTable is very inelegant, with duplication of data
between the keys and the values due it being a
nsRefPtrHashtable<ValueObserverHashKey, ValueObserver> and ValueObserver being
a subclass of ValueObserverHashKey(!)
This extra layer might make sense if there were a lot of commoning up
happening, but there's not. Across all process kinds there is an average of
between 1.2 and 1.7 closures per ValueObserver. The vast majority have 1
closure, and there are a handful that have multiple; the highest number I've
seen is 71.
(Note that this two-layer design probably seemed more natural back when libpref
was spread across multiple files.)
This patch removes the ValueObserver layer. The only tricky part is that there
is a notion of a MatchKind -- ExactMatch or PrefixMatch -- which exists in the
ValueObserverLayer but not in the CallbackNode layer. So the patch moves the
MatchKind into the CallbackNode layer, which is straightforward.
On Linux64 this reduces memory usage by about 40 KiB in the parent process and
about 30 KiB in each content processes.
The performance implications are minor.
- The list of CallbackNodes is a bit longer, so when a pref is changed we must
check more nodes. But we avoid possibly doing prefname matching twice.
- Callback registration is much faster, just a simple list prepend, without any
hash table insertion required.
- Callback unregistration is probably not much different. There is a longer
list to traverse, but no hash table removal.
- Pref lookup is by far the hottest libpref operation, and it's unchanged.
For perf to be genuinely affected would require (a) a *lot* more
almost-duplicate callbacks that would have been commoned up, and (b) frequent
changing of the pref those callbacks are observing. This seems highly unlikely.
MozReview-Commit-ID: 6xo4xmytOf3
--HG--
extra : rebase_source : cf9884a8a40b2cc3b00ab165ae5ab4ec3383f72d
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : fb7af066adfa0491a79fae6282a62b08661553c8
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
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
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
Behaviour is controlled through the media.navigator.video.vp9_preferred preference.
MozReview-Commit-ID: J06ArFYNmTk
--HG--
extra : rebase_source : a25bd4783fde0acf8291ee440745a619d3fa7db8
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
Brindusan Cristian
Chung-Sheng Fu
Alastor Wu
Bogdan Tara
Nicholas Nethercote
Makoto Kato
Dorel Luca
Jean-Yves Avenard
Emilio Cobos Álvarez
Jonathan Kingston
Dão Gottwald
Johann Hofmann
Sebastian Hengst
bechen@mozilla.com
Chun-Min Chang
Cosmin Sabou
Noemi Erli
Florian Quèze
Ciure Andrei
Botond Ballo
sotaro
arthur.iakab
Brian Birtles
Mike Hommey
Nika Layzell
Gabriele Svelto
Ryan Hunt
Nicolas Silva
Phil Ringnalda
shindli
Kearwood "Kip" Gilbert
Andrea Marchesini
Coroiu Cristina
Cervantes Yu
Tiberius Oros
Tooru Fujisawa
Michal Novotny
Martin Stransky
Valentin Gosu
Margareta Eliza Balazs
Jonathan Watt
Rob Wu
Tom Ritter
Tim Huang
Timothy Guan-tin Chien
Robin Grenet
Christoph Kerschbaumer
Matt Woodrow
Ethan Lin
Ryan VanderMeulen
Paul Adenot
Stone Shih
David Teller
Gijs Kruitbosch
Narcis Beleuzu
Jeff Gilbert
Nicolas B. Pierron
Christian Holler
Andreas Pehrson