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
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
Carsten "Tomcat" Book
Ryan VanderMeulen
Masayuki Nakano
Olli Pettay
Bob Owen
Paul Bignier
Wes Kocher
Matt Brubeck
Martin Robinson
Ehsan Akhgari
Nicolas B. Pierron
Jean-Yves Avenard
Honza Bambas
Markus Stange
Kaku Kuo
Blake Kaplan
Jessica Jong
Dragana Damjanovic
Botond Ballo
Xidorn Quan
Gerald Squelart
Landry Breuil
Kris Maglione
Chris Pearce
Valentin Gosu
Eden Chuang
Jim Mathies
Mike Taylor
Sebastian Hengst
Daosheng Mu
Andreas Farre