image.animated.decode-on-demand.threshold-kb is the maximum size in kB
that the aggregate frames of an animation can use before it starts to
discard already displayed frames, and redecode them as necessary. The
lower it is set to, the less overall memory we will consume at the
expense of execution time for as long as the tab with the animation(s)
above the threshold are kept open.
image.animated.decode-on-demand.batch-size is the minimum number of
frames we want to have buffered ahead of an animation's currently
displayed frame. The decoding will request this number of frames at a
time to maximize use of memory caching. Note that this is related to the
above preference as well; increasing the batch size will in effect raise
what the minimum threshold. This simplifies the logic in patches later
in the series.
For FF59, we disabled WebVR for macOS before allowing it to ride the trains to release. Softvision was unable to verify for QA due to challenges getting a working hardware configuration for macOS VR at SoftVision.
We have since gained approval from the Firefox Release Team to re-enable WebVR for macOS in release for FF60.
Essentially, we need to reverse the changes in bug 1426500 and uplift to FF59/Beta before the next cycle.
--HG--
extra : rebase_source : 1b0c68b130f869f0e71cf2d93db92bb78dddc79b
This patch disables device sensors except orientation by default.
It implements per-sensor prefs to disable orientation, motion, proximity and ambient light
selectively. The patch also makes the pref checks happen at runtime (versus on process
start) using Preferences::AddBoolVarCache.
The patch also removes the related Event constructors also.
MozReview-Commit-ID: EA8ARjjtlkF
--HG--
rename : dom/events/test/test_bug742376.html => dom/events/test/test_deviceSensor.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_disabled_events.html
rename : dom/events/test/test_eventctors.html => dom/events/test/test_eventctors_sensors.html
extra : rebase_source : 39da98ac9226ac727f5197d28561b0b762da06f4
Before Firefox 58 we collected extended collection from users on nightly,
aurora, and beta. Then we had to change things (see bug 1406391).
In doing so, we accidentally stopped receiving data from "release candidate"
beta builds. This patch resumes that collection by detecting an RC build as
having a MOZ_UPDATE_CHANNEL of "release", but an app.update.channel of "beta"
MozReview-Commit-ID: 3EzzDtQj8Kw
--HG--
extra : rebase_source : 371d2b804cad4fff3fc6a954621e651940867435
The canvas prompt is extremely annoying. It happens everyone, automatically. And in
99.9% (not scientific) of cases it is not triggered by user input, but my automatic
tracking scripts.
This commit will automatically decline the canvas read if it was not triggered by
user input.
Just in case this breaks something irrepairably, we have a cutoff pref.
We don't intend to keep this pref forever, and have asked anyone who sets it to
tell us why.
MozReview-Commit-ID: CxNkuraRWpV
--HG--
extra : rebase_source : 12cfc94cecbd378c0859ae50066c6338bcaa6692
image.mem.volatile.min_threshold_kb is the minimum buffer allocation for
an image frame in KB before it will use volatile memory. If it is less
than it will use the heap. This only is set to > 0 on Android.
image.mem.animated.use_heap forces image frames to use the heap if it is
for an animated image. This is only enabled for Android, and was
previously a compile time option also for Android.
"Include what you use."
--HG--
extra : rebase_source : 2239a380029e0efbc9dd3042459222a67c38d70f
extra : amend_source : 4453c32cc469caa592049167205666997f1a1e7b
extra : histedit_source : a533edd4a4d3d0642b08989e93674661d27baa6a%2C37d27eeef9580381ccc0de8507f60166dabf1730
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
This was first suggested 17 years ago!
The error recovery works by just scanning forward for the next ';' token.
This change allows a lot of the gtest tests to be combined.
MozReview-Commit-ID: CbZ2OFtdIxf
--HG--
extra : rebase_source : 5a43fff06e88b45a095725856bbe1e6b5470c9a0
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
The meaning of "possibly-changed" is provided by the big comment above
MustSendToContentProcesses.
On a new profile this reduces the number of prefs sent like so:
- Command-line: 222 --> 3
- IPC: 3129 --> 130
On an older profile:
- Command-line: 222 --> 3
- IPC: 3165 --> 180
MozReview-Commit-ID: DcgedhXhZd8
--HG--
extra : rebase_source : acef424fab5031347cbcbd5c3e6a24ee66895ef9
No Nightly testers don't report new compatibility issue. Additionally, if we
make Firefox use <div> as defaultParagraphSeparator in release build, web
services may stop supporting our current behavior quickly because they can
get rid of hack for us. Therefore, we should do this in the cycle of Gecko 60
which is next ESR. If we did this later, ESR users may have become not to be
able to use existing web services suddenly immediately after we did this in 61
or 62. We should avoid this bad scenario.
MozReview-Commit-ID: 7Um79Ky7n8i
--HG--
extra : rebase_source : 45c6d521ddc1166decb60cc8437ffb703b1e9aff
This has two advantages. First, it reduces memory usage, as per the following
calculation.
64-bit:
- Old sizes:
- sizeof(Pref) = 32
- New sizes:
- sizeof(PrefEntry) = 16
- sizeof(Pref) = 32
- Change:
- -16 per empty slot in the hash table
- +16 per used slot
- A win if less than half the table slots are used
32-bit
- Old sizes:
- sizeof(Pref) = 20
- New sizes:
- sizeof(PrefEntry) = 8
- sizeof(Pref) = 16
- Change:
- -12 per empty slot in the hash table
- +4 per used slot in the hash table
- A win if table is < 75% full
Table size:
- The table is currently less than half full: ~3100 used out of 8192 slots.
- The table is always <= 75% full, because that's the max load factor (for
non-gigantic tables).
- Therefore it's a win for both cases.
Old sizes, chrome process, 64-bit:
> 718,712 B (00.36%) -- preferences
> +--262,176 B (00.13%) -- hash-table
> +--197,384 B (00.10%) -- callbacks
> +--114,688 B (00.06%) -- pref-name-arena
> +---92,240 B (00.05%) -- root-branches
> +---30,456 B (00.02%) -- string-values
> +---21,688 B (00.01%) -- cache-data
> +-------80 B (00.00%) -- misc
New sizes, chrome process, 64-bit:
> 672,568 B (00.41%) -- preferences
> +--181,160 B (00.11%) -- callbacks
> +--131,104 B (00.08%) -- hash-table # smaller
> +--114,688 B (00.07%) -- pref-name-arena
> +--101,152 B (00.06%) -- pref-values # new
> +---92,240 B (00.06%) -- root-branches
> +---30,456 B (00.02%) -- string-values
> +---21,688 B (00.01%) -- cache-data
> +-------80 B (00.00%) -- misc
Old sizes, smallest content process, 64-bit:
> 500,712 B (02.89%) -- preferences
> +--262,176 B (01.51%) -- hash-table
> +--114,688 B (00.66%) -- pref-name-arena
> +---62,520 B (00.36%) -- callbacks
> +---30,456 B (00.18%) -- string-values
> +---17,832 B (00.10%) -- cache-data
> +---12,960 B (00.07%) -- root-branches
> +-------80 B (00.00%) -- misc
New sizes, smallest content process, 64-bit:
> 470,792 B (02.70%) -- preferences
> +--131,104 B (00.75%) -- hash-table # smaller
> +--114,688 B (00.66%) -- pref-name-arena
> +--101,152 B (00.58%) -- pref-values # new
> +---62,520 B (00.36%) -- callbacks
> +---30,456 B (00.17%) -- string-values
> +---17,832 B (00.10%) -- cache-data
> +---12,960 B (00.07%) -- root-branches
> +-------80 B (00.00%) -- misc
The "hash-table" values drop by more than the size of the new "pref-values"
value.
On 64-bit, this reduces memory usage per process by 30--40 KB. On 32-bit, the
number is slightly more.
The second major advantage of this change is flexibility -- it opens up the
possibility of different Pref objects being stored in different way. For
example, static Prefs could be stared statically, letting them be shared
between processes so long as they don't change (see bug 1437168).
MozReview-Commit-ID: KmgbJaoOQ1J
--HG--
extra : rebase_source : 9f8201583432c1414ab3e17e80fe23a369ac264b
This feature is confusing for Nightly users in its current state, and the
suggested websites, in foreign languages, may look worrisome to some.
Bug 1340663 must figure out these issues before re-enabling the feature.
MozReview-Commit-ID: 6RJ0Ff1B3AJ
--HG--
extra : rebase_source : 569b5ae833c4f5c05656522d0d9d0ad00679c370
This construct is nicer than NS_INTERFACE_MAP_BEGIN and assures the
reader there's no weirdness in the QI implementation. This change does
mean that PGO doesn't get an opportunity to measure the frequency of
which interfaces are QI'd most often. I think this is probably an OK
tradeoff to make, given the prevalence of NS_IMPL_QUERY_INTERFACE
elsewhere in the codebase.
The one thing we have to ensure with this change is that the ambiguous
QI to nsISupports uses the proper class after the change. The
NS_IMPL_QUERY_INTERFACE macro chooses the first interface listed to
disambiguate the cast to nsISupports.
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
This lets us have a proper constructor for Pref, which is nice.
The patch also adds a missing case to PrefTypeToString(), and reorders the
fields in Pref to be more sensible.
MozReview-Commit-ID: A01ULF4q08O
--HG--
extra : rebase_source : 835e494ad18e3ea4de9f02beca8266551bfffe5e
mZips key is used only for internal hashtable lookups, so GetPersistentDescriptor is suitable.
MozReview-Commit-ID: 48wDOSjyo3r
--HG--
extra : rebase_source : 03c4b47812dade1d3e321727aafacfbc12bcbf32
extra : intermediate-source : 85a0b6bc25a1f960767ac28ff23a8c26829946a2
extra : source : 544bf26e258d42c835c80672416b0e29a48ba33b
They currently fail to pass on `aKind`, always getting the user value (when
possible). There are three callsites that are affected:
- nsSHistory::Startup, docshell/shistory/nsSHistory.cpp.
- FeatureState::SetDefaultFromPref(), in gfx/config/gfxFeature.cpp.
- gfxPlatform::InitOMTPConfig(), in gfx/thebes/gfxPlatform.cpp.
The patch also adds a gtest that would have failed prior to the fix.
MozReview-Commit-ID: L0U1XQmPUFc
--HG--
extra : rebase_source : d51d09836609c5a45d0b9f20570427681d8b3309
Similar to ATOK, Japanist 10 requests all or part of composition string.
If we return TS_E_NOLAYOUT in this case, you'll see candidate window at
top-left of the screen.
For avoiding this issue, we should not return TS_E_NOLAYOUT to Japanist 10
when the query range is in composition string.
MozReview-Commit-ID: 2OPafUO5PQC
--HG--
extra : rebase_source : bd7a594d8d3540374d61860651b69528aa6e3793
This patch rearranges these functions so that nsPrefBranch::GetPrefType() calls
into Preferences::GetType(), because all other nsPrefBranch methods depend on
Preferences methods.
The patch also removes the `aKind` argument from GetType(), because it has no
effect -- a pref only has one type, regardless of whether it has a default
value, a user value, or both.
MozReview-Commit-ID: J3vxFPaP8S3
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <