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
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 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
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
This is a mixture of clang-format and manual restyling.
MozReview-Commit-ID: ApLqaQ3KZ5S
--HG--
extra : rebase_source : 4b4ac2f7f05eaa39181005655a62234275b96ff6
This updates test_libPrefs.js so that it actually runs all the observer
portion of it's tests. Previously the observer callback would get hit before
the next do_test_pending call could be run, thus causing the test to end.
An additional test was added to confirm that registering for multiple prefs on
a non-root pref branch works as intended.
Don't send any preferences that have a string value that is longer
than MAX_ADVISABLE_PREF_LENGTH. This is intended to mitigate OOM
issues, as I've seen a parent process crash trying to create a 100mb
message to send to the child. Such users likely cannot use e10s at
all.
This has a test for all combinations of setting the default and user
values of a preference to large or small string values, or not setting
them at all.
I manually verified that filtering out preferences reduces the size of
the IPC::Message that is sent to the child by printing out the size of
the reply message in PContentParent::OnMessageReceived().
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.