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