Currently we preallocate 4 shmems for ferrying video frames between the GMP and CDM
procecss. Our telemetry indicates that 88% of PChromiumCDM instances need only 4.
So 12% are finding that insufficient, and are taking the slow path and sending frames
back to the content process via a non-shared path while they allocate more shmem.
If we increased our pre-allocation to 6 shmems, we'd guess correctly for 97%, and thus
we'd avoid the slow path more often.
MozReview-Commit-ID: 9HcrlskiCPq
--HG--
extra : rebase_source : 0b3ba593b7b8c9739221c056687f0f3f0fb3019d
Don't go over the lowest of 'media.memory_caches_combined_limit_kb'
(kilobytes) or 'media.memory_caches_combined_limit_pc_sysmem' (percents of
system memory).
Added more logging around creation/destruction of MediaCaches.
MozReview-Commit-ID: Cdz4ycyn1RR
--HG--
extra : rebase_source : 63168234f186c3ef9c0289a189a647d67d8526a4
This commit ties it all together by dispatching keyboard actions to scroll targets
in response to keyboard inputs when we have current and valid focus state.
MozReview-Commit-ID: G7rZiS3FH5e
--HG--
extra : rebase_source : 10129d417fe8ef576cac5bda3157dd8f65b5843a
extra : histedit_source : be651a33f787f68bc764988ddc073d346e854491
Easy Changjei, a Traditional Chinese IME, isn't available on Firefox because:
* The vendor has gone and nobody keeps maintaining it.
* It crashes at first key press since it was built with older Visual Studio and depends on the version's CRT.
Therefore, we don't need to support it anymore.
MozReview-Commit-ID: LjyAvWsrlJ1
--HG--
extra : rebase_source : 481c4fdd5bbd6ed9984a101226f5232da9705430
Includes re-importing gyp files removed from upstream in v56, and then
updating them to match the BUILD.gn file changes.
--HG--
rename : media/webrtc/trunk/webrtc/call/audio_send_stream.cc => media/webrtc/trunk/webrtc/call/audio_send_stream_call.cc
TIPs (and normal keyboard layouts) don't need IMC on focused window. So, in most environment, it's not necessary to restore default IMC of focused window.
Therefore, this patch makes IMEHandler not restore default IMC unless legacy IMM-IME is active and disassociate IMC from focused window when IMM-IME isn't active.
However, this is risky change. Therefore, the new behavior is disabled in default settings. On the other hand, we need the new behavior only when MS-IME for Japanese is active on Win10. Therefore, this patch adds a pref to enable/disable the hack and make it true in the default settings.
MozReview-Commit-ID: KAVxVT9CrsW
The Flash infobar is showing up a bit too often. There are a few changes planned to address this. One of them is a list that will contain sites that should never display infobars. This patch allows the list to be downloaded from Shavar and updated via the URL classifier.
MozReview-Commit-ID: BgAaysyRzIE
--HG--
extra : rebase_source : a5f569a3bc60134938e9dc937cb5cfb84222a52b
extra : amend_source : 543e3c38b63d7b958c633c38e066ab9b47a76a01
We enable by default the VP9 hardware decoder on intel GPU.
MozReview-Commit-ID: FzMzbpZErjQ
--HG--
extra : rebase_source : f34c969f7dda1ef24224e982f31d5e43cfae7cc0
I thought of fixing this in the e10srollout addon because DevEdition is now
built off of Beta, but it would only serve to complicate the addon even more
and expose us to more risk every time we touch it. Also, DevEdition stayed on
the Aurora update channel and who knows if we're going to change that in the
future. Special casing DevEdition (via AppConstants) is possible, but it was
going to get messy pretty quickly. This is probably the most straightforward
way to make this all work.
MozReview-Commit-ID: 6WPjBawUutz
--HG--
extra : rebase_source : 156846085e1e3db7cd4924793a1de5d9336fab1c
8KB by default, otherwise using the next power of two from the given
media.cache.resource-index (but staying within 32B-128KB).
'0' means we don't want to use caching.
MozReview-Commit-ID: 8LmS15Ft2MA
--HG--
extra : rebase_source : 992f377a07b7ab173a64fcfbfe45df1da87df31e
Our canplaythrough logic is opaque to the users, so I expect that our recent
change to throttle when we hit the readahead limit would be confusing to users;
those on a slow connection would want their media to prebuffer, and not expect
the download to stop part way through. They would think that Firefox had
stalled at an arbitrary point for some unknown reason, i.e., they'd think
Firefox was broken. So I think we're better to instead only throttle if the
network is good enough that the user probably doesn't worry about the download
not keeping up with playback.
We should restore the previous behaviour on mobile of throttling when the
download reached the readaheadd limit regardless of canplaythrough or network
speed, as the calculus is different on mobile; the user may also be concerned
about battery life, or hitting their data cap. And often the faster the
cellular network is, the more expensive data on it is.
So this patch changes us to throttle when we reach the readahead limit only if
the network is fast, where fast is defined as being able to stream at twice the
rate estimated to be required to playback without stalling.
It also adds a pref to revert to the old behaviour of not considering the
network speed, which we enable on mobile to restore it to its previous
behaviour.
MozReview-Commit-ID: KLIGaQZV6dX
--HG--
extra : rebase_source : c2e0c6be3158fa661be49d1267d976af43aff6d7
The previous limits were chosen a bit arbitrarily, and didn't trigger racing too often. These limits are also quite arbitrary, but should cause us to race more.
These limits can be removed once we implement bug 1325331 and we can make a fair approximation regarding the cache latency.
MozReview-Commit-ID: CUssxUrs1Wu
--HG--
extra : rebase_source : 0465b921722e398d3b954ad8a5b4531fcebea371
Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
Based on the telemetry that landed as part of bug 1336904, Safe Browsing
updates are failing too often: https://mzl.la/2qGkOPS
This should enable browsers on slower networks to reach the update
servers while still putting a reasonable bound on how long the update
thread can be blocked.
MozReview-Commit-ID: 6puVtpMT87K
--HG--
extra : rebase_source : 4b68bb6778b45068bb8a2d0dbdfddfe24a6b022f
This also activates the Favor fallback mode to give preference for HTML <video> content over Flash objects, and to not load Flash when the page has not speficied a src url (as the data attribute).
MozReview-Commit-ID: Lo4eWGbWyOt
Removing support for this preference means that mReuseLoaderGlobal
will always be false, which lets us eliminate that field, and remove a
lot of code.
This also means that false is always passed to
PrepareObjectForLocation for aReuseLoaderGlobal.
ReadCachedFunction is no longer used, so it is deleted.
MozReview-Commit-ID: 5JD24EYVcQf
--HG--
extra : rebase_source : 3b23b4b8d2b1a2f6a53223477afb4cb13b8a671c
Functions and Preference related to mTableFreshness and gFreshnessGuarantee
could be removed since we will no longer require them.
MozReview-Commit-ID: IAa0UHLSQ56
--HG--
extra : rebase_source : daa959340c92cfcb751fe8d0548d30762db3783e
This allows the feature to ride the trains later than async scrollbar
dragging itself, if desired.
MozReview-Commit-ID: 73ZlCqM5hMN
--HG--
extra : rebase_source : dabc4a4b72210133d8b62256510213183312f18f
People seem to be turning on this pref in the wild and generating crash reports
which are wasting time and energy of people who have better things to do.
MozReview-Commit-ID: 5VfjKaDluYJ
--HG--
extra : rebase_source : fa2237835d842ddb118c6ba6096f6b703aef9d81
The OrInsert() method adds the new entry to the hashtable if needed, and
returns the newly added entry or the pre-existing one. It allows for a
more concise syntax at the call site.
The login manager searching logins for autofill may trap the user
in an infinite loop of master password prompts until the user enters
the correct master password. To prevent that, we're adding a timeout
to showing the master password prompt for autofill after it was last
cancelled.
MozReview-Commit-ID: JcmTDU6CKKA
--HG--
extra : rebase_source : 6f4d2c59360963f53972b812d999756637434415
Removes references to now unused pref that was added in bug 868441 and removed in bugs 913807 and 1054572. It also removes some leftovers from http channel which have not been removed in those 2 bugs.
// When non empty all non-localhost DNS queries (including IP addresses)
// resolve to this value. The value can be a name or an IP address.
// domains mapped to localhost with localDomains stay localhost.
pref("network.dns.forceResolve", "");
Testing is the primary use case here - replay captive data on a 'fake
server' by directing all traffic to it at the DNS level. Chrome has
something similar.
MozReview-Commit-ID: 7AOgQZpZKec
--HG--
extra : rebase_source : ad2648a701fffecaae47cbfae17e7aa6badd50ee
These timeouts will ensure that we don't block the Safe Browsing update thread
for too long when we encounter slow or bad network conditions.
MozReview-Commit-ID: AJfR193cTf8
--HG--
extra : rebase_source : 5ae14f204ed88691fac4e9ba8c8202b8aa79b657
In bug 1353123 it was decided to not extend this telemetry, so it will
expire in this release. Given that, and the fact that bug 1329336 has
disabled the feature already, it's time to remove the probe.
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements or to call a function for side effects within an expression.
modules/libjar/nsZipArchive.cpp:651:25 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: 9PjB915D81f
--HG--
extra : rebase_source : c494c2f4a8291d6c08f02765e988c1fd14079e54
extra : source : 3643e37b615c4461b6a9359856731252acc36465
This rolls browser.tabs.animate, browser.fullscreen.animate, and
alerts.disableSlidingEffect into a single pref; if any of these are disabled,
we'll disable the new pref too (toolkit.cosmeticAnimations.enabled). Most
future animations will also be subject to this pref.
MozReview-Commit-ID: 77pLMtERDna
--HG--
extra : rebase_source : 8939e453c2277caa4a90123ae09bb542aaa421ed
Per discussion on dev.platform, this is risk-prone, and we want more
time baking on nightlies and early betas to see if it causes problems.
MozReview-Commit-ID: CaprjWxYfbC
--HG--
extra : rebase_source : d8adf27d78ea258af88d4f05d87cd0caf9c5bdb9
The media prefs "media.decoder-doctor.decode-{errors,warnings}-allowed" list
which decode issue codes will show the "Report Site Issue" notification.
Default: NS_ERROR_DOM_MEDIA_DEMUXER_ERR and NS_ERROR_DOM_MEDIA_METADATA_ERR,
which are the kinds of errors we currently care most about, and have more
chance to fix.
MozReview-Commit-ID: JbY2pwv4TXP
--HG--
extra : rebase_source : 65809f5eb3ace85e25b01c0d1cdfdd068c467ca0
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
This appears to have been "broken" since bug 510844, for some value of
broken where it doesn't actually cause any problem in practice because
of how zlib behaves.
That is, in practice, we always still have input to process when there's
pending output. But while that's true with zlib, that's not necessarily
true for other decompressors (e.g. brotli).
--HG--
extra : rebase_source : 7572139f8e2b3df8c6b68123c0a14524dddb3faf
Since the allow list contains both hostnames and certificate hashes, it makes sense
to use it on all platforms.
MozReview-Commit-ID: 1icRFYhhnAY
--HG--
extra : rebase_source : bcb6113090546cdca2b4f2dd120db98ffb511b0d
This is regression-prone, so dev.platform discussion concluded we want
it behind a pref. We might turn the pref off for beta and/or release
for now as well.
MozReview-Commit-ID: 2H2et3RElZx
--HG--
extra : rebase_source : baf7e679ca1ee16016666d7697990c4f64ecf83e
After this patch is introduced, url-classifier will return merged classify result
from V2 and V4.
--HG--
extra : rebase_source : 1940f8617547878b87a5808479ef9d46e6722a92
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 4beba0212411a0f5867feb506bbf732f5a934fa9
This adds a PrefName wrapper that allows use to avoid copying the pref name
string in the fast root pref branch case, but also allows to create a new
string in the slower non-root pref branch case. By creating a new string we
avoid the odd behavior of mutating the pref branch name with each retrieval.
MozReview-Commit-ID: HGCLbpGmKrr
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.
If 'media.playback.warnings-as-errors' is true, demuxing and decoding warnings
(i.e., non-fatal errors) will be treated as errors, causing playback to fail.
Currently set to false by default.
This could be later changed to catch and diagnose more issues.
MozReview-Commit-ID: BTaZ6TbIbNG
--HG--
extra : rebase_source : bacc24a46f588dd344e6d46178ae2d2c58882fcb
The racing algorithm is quite simple at this point:
If racing is enabled, the request is allowed to hit the network, and the cache queue size is bigger than a certain threshold, then we trigger the network right before we query the cache.
MozReview-Commit-ID: JklG4P1eRyO
