This was previously limited to 2 per principal and 4 total on
mobile. Mobile GPU drivers have progressed a lot since the limit was
put in place, and the strict limit is causing webcompat issues on
google maps.
Increase to 8 per principal and 16 in total, bringing us
closer in line with Chrome. Make these limits contrallable via a pref
so that if there are any problems it is easy to change.
MozReview-Commit-ID: 8Tsbrjr4KCE
--HG--
extra : rebase_source : 8efd43265a665237a8bfcb689f5fc758466bcd71
This code is used to detect too-early accesses of prefs in content processes.
The patch makes the following changes.
- New terminology: "early" prefs are those sent via the command line; "late"
prefs are those sent via IPC. Previously the former were "init" prefs and the
latter didn't have a clear name.
- The phase tracking and checking is now almost completely encapsulated within
Preferences.cpp. The only exposure to outside code is via the
AreAllPrefsSetInContentProcess() method, which has a single use.
- The number of states tracked drops from 5 to 3. There's no need to track the
beginning of the pref-setting operations, because we only need to know if
they've finished. (This also avoids the weirdness where we could transition
from END_INIT_PREFS back to BEGIN_INIT_PREFS because of the way -intPrefs,
-boolPrefs and -stringPrefs were parsed separately.)
MozReview-Commit-ID: IVJWiDxdsDV
--HG--
extra : rebase_source : 8cee1dcbd40847bf052ca9e2b759dd550350e5a1
The default path and the user path are entirely disjoint, and some of the
arguments only apply to one of the paths, so splitting it into two functions
makes things a bit clearer. The aForceSet arg is also renamed aFromFile.
MozReview-Commit-ID: LYtrwz5JHiN
--HG--
extra : rebase_source : c66c39b0869c0fae6bbecc55f42e0842f5b40f46
It's not possible for a string value to be nullptr.
MozReview-Commit-ID: 13X28YObvwp
--HG--
extra : rebase_source : 01c8327784e356e71511eedea17d1d8e0d008776
pref_SetPref() is now the only function that runs in the content process and
calls HandleDirty(). So this patch moves the parent process check out of
HandleDirty() into pref_SetPref().
The patch also adds assertions to a couple of other parent-process-only
functions.
MozReview-Commit-ID: KurXKMl4IIb
--HG--
extra : rebase_source : fefb67f6e48ec83368b6170aba050883d512eb22
This includes removing a bunch of low-value ones.
MozReview-Commit-ID: LGS9M9TCL4e
--HG--
extra : rebase_source : 707a68baebc71af572974943702b57246b080533
- Segoe UI Emoji for Windows 8+
- EmojiOne Mozilla for Windows 7
- Apple Color Emoji for OSX
- EmojiOne Mozilla for GTK(Linux). fontconfig doesn't support emoji as family name.
- Noto Color Emoji for Android
MozReview-Commit-ID: GOkOFRujk93
--HG--
extra : rebase_source : e8bae62d555440d9881f111fb26393d59fd15ba4
The code to migrate from the toolkit.telemetry.enabledPreRelease pref to
toolkit.telemetry.enabled was added to Firefox 31 in bug 986582. It should be
safe to remove now.
MozReview-Commit-ID: JBkn20bUQXx
--HG--
extra : rebase_source : 1fa65f1f5b8b6251af7a888959d931652363fc9a
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
