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
Chris Pearce
Carsten "Tomcat" Book
Valentin Gosu
Ryan VanderMeulen
Eden Chuang
Jim Mathies
Honza Bambas
Sebastian Hengst
Daosheng Mu
Andreas Farre
Ethan Tseng
Manish Goregaokar
Bruce Sun
Mats Palmgren
Iris Hsiao
btian
Francois Marier
Xidorn Quan
Wes Kocher
Ben Kelly
Kartikaya Gupta
Alexis Beingessner
Ethan Lin
Morris Tseng
Andrew Swan
Nicolas B. Pierron
Bob Owen
Felipe Gomes
Phil Ringnalda