Otherwise we might fail the assertion |!mRequest| in the destructor of MozPromiseRequestHolder.
MozReview-Commit-ID: HsVD2re0R7e
--HG--
extra : rebase_source : c023899d92501dd3e275000c9ef0eb50df117236
The assertion fails if we call SeekToNextFrame() on a video which has done
video decoding but keeps decoding audio.
MozReview-Commit-ID: F9qpfYI2Ajo
--HG--
extra : rebase_source : 73ab2f146101b0ef5a55ee26436b005386164c9d
The previous version of this test assumed that it was in control of all
processes (except for a single one that was hanging around). That meant that
changes to the environment, such as running it on a different branch could
cause it to fail. Now we explicitly test that creating new tabs creates a new
content process (and that the final tab creation *doesn't* do so) with a
sanity check that new ContentParents don't reuse the same underlying OS
process. Because we're now explicitly testing what we want, this works whether
the current branch holds a random extra process alive or not.
MozReview-Commit-ID: CNgLGL32Iog
--HG--
extra : rebase_source : f27d132d00bdd94d7034cc63c83bbacfe04bde0c
In bug 1345898, we flushed the decoder rather than draining it when we are waiting for data.
However, more accurately we are in the middle of an internal seek.
There are more occasions during which we could be performing an internal seek during which we don't care about the frames being decoded. So flushing is better.
MozReview-Commit-ID: ATpTFdp8mRL
--HG--
extra : rebase_source : 60649f15eb9fcc52c31484f7180c60f516f3bc4e
Since our platform support is Windows 7+, we can replace nsWin32Locale::GetXPLocale with LCIDToLocaleName.
MozReview-Commit-ID: Tboh4P6cLc
--HG--
extra : rebase_source : 7dd6614b0aca25e82d194d104409400e1cc6b4a8
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 64395c5fdf25deebd60dfbf2cf5df3cbf7ca8abb
extra : amend_source : 0a3f13419c050662680f2bd110d724b3bf991732
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 59e5b84cb431f3ca28287d30a3da8fbea1363ec5
Still left TODO:
* add an aboutWebrtc.js section
* write tests
MozReview-Commit-ID: DwFxq19KWeu
--HG--
extra : rebase_source : fad3018d851316af83df48c62db16028a1a84b5c
Since the ref-sample made by linux, the mac and windows platforms need fuzzy.
And on windows platform, the first frame is different to other platform, skip it first.
Android platform somehow can not load the video src.
MozReview-Commit-ID: A0VbEcNSmck
--HG--
extra : rebase_source : 266f0012d460b8fd6b62ac1d2878dc9aa686f9a8
Also, close the FD if FileBlockCache::Closed() was called between Init() and
SetCacheFile().
MozReview-Commit-ID: 5p8NslMow7D
--HG--
extra : rebase_source : a465020edfedf91454ba6c2ae307ae9e6977f47f
This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.
MozReview-Commit-ID: H0gF3FqZsU6
--HG--
extra : rebase_source : 54d38d24b40014351f943bff6860f5de9fc2f418
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
In the nsWindowMemoryReporter.cpp / nsArenaMemoryStats.h I'm only
including the concrete frame classes now - we obviously never have
instances of the other IDs so there's no need to collect stats for them.
MozReview-Commit-ID: 48uFCZ3xKBC
SetCursorPos is used by Flash's relative cursor motion behavior. It is blocked by the plugin sandbox. This patch allows it to run by proxying it on the main process.
--HG--
extra : histedit_source : 85515d398c0c107c2258185c0591a943b26e724a
HTMLInputElement::IsValueEmpty uses DocumentEncoder when input element has focus. DocumentEncoder is slow, so we should use fast path (nsTextEditorState::HasNonEmptyValue) to check whether value is empty.
MozReview-Commit-ID: 1JxAeZ6z5A4
--HG--
extra : rebase_source : 8cf89721bf59f0bde09e217428bb593ad6d328de
When we send out a prefetch request, we act as if the load came
from one of the possibly many documents containing <link> element
for the given URL. The docgroup assigned to this request is
derived from this document. Later, when the load finishes, the
OnStopRequest code runs in a runnable labeled with this
docgroup. OnStopRequest dispatches a load event to *all* the link
elements, including some that might be in different docgroups
from the OnStopRequest runnable. This generates an assertion.
To fix this, I decided to dispatch the load events
asynchronously. I'm hoping the extra round trip through the event
loop shouldn't hurt us too much since I doubt anyone actually
listens for these events.
MozReview-Commit-ID: FTkjuHO7RFp
When we send out a prefetch request, we act as if the load came
from one of the possibly many documents containing <link> element
for the given URL. The docgroup assigned to this request is
derived from this document. Later, when the load finishes, the
OnStopRequest code runs in a runnable labeled with this
docgroup. OnStopRequest dispatches a load event to *all* the link
elements, including some that might be in different docgroups
from the OnStopRequest runnable. This generates an assertion.
To fix this, I decided to dispatch the load events
asynchronously. I'm hoping the extra round trip through the event
loop shouldn't hurt us too much since I doubt anyone actually
listens for these events.
MozReview-Commit-ID: FTkjuHO7RFp
We no longer support decoding non-EME audio via GMPs, so it's not possible
for a GMP to be used for decoding content that passes through a WebAudio
BufferDecoder. So we don't need to keep the GMPCrashHelper around in the
WebAudio code. If EME content is being used, there will be a crash helper on
the MediaKeys object anyway.
MozReview-Commit-ID: BThxnTANSTD
--HG--
extra : rebase_source : 2c2ce4e982dcef6e3985c426386974083505c953
We should only render the Subtitles/Captions cue on the screen. In addition, rename the activeCues to showingCues.
Because the meaning of "active" and "showing" are different. Showing means we can see the cue on the screen, active means the current playback time touches the cue.
MozReview-Commit-ID: 1BfHhxFXBDP
--HG--
extra : rebase_source : 2c4d6b0b052758f1bb01a7794365bf75b556304c
This event is no longer necessary, since checking nsITabParent.hasPresented is enough to know
if we need to blank out the tab or not.
MozReview-Commit-ID: 445XMqhorxC
--HG--
extra : rebase_source : 1a05de827502c409d979a621471978b08ce39fb2
The U2F Soft Token, due to its usage of NSS, has to have const values be
marked non-const - but no such limitation should exist for other implementations
of U2F, so this patch moves the const_cast-ing from the U2FTokenManager-level
down to the U2FSoftTokenManager, where it is actually necessary.
Credit to Axel Nennker for this patch.
MozReview-Commit-ID: Kw6zfTDI3GL
--HG--
extra : rebase_source : 90e31e2da9e021043509653a476ddaae03078e55
Changed the type of argument |targetFilter| of NukeCrossCompartmentWrappers()
from CompartmentFilter to JSCompartment* because it is always a single target
compartment, and we can optimize the iteration not to iterate the outer map.
MozReview-Commit-ID: 7cDCgJI0H9z
--HG--
extra : rebase_source : 4973dfd4c3326bf48b78088979962e425e35030c
This will enable us to pre-allocate the correct number of shared memory buffers
that we pre-allocate for sending video frames between the CDM and Gecko. That
means we won't need to take the slow path to recover from underestimating how
many shmems we need.
MozReview-Commit-ID: Q4mX2rYMz3
--HG--
extra : rebase_source : f9573cfbf4e65013803b46c0909be2c68566e512
Andrea Marchesini
JW Wang
Kaku Kuo
Blake Kaplan
Ryan VanderMeulen
Tobias Schneider
Christoph Kerschbaumer
Carsten "Tomcat" Book
Jean-Yves Avenard
Makoto Kato
Ehsan Akhgari
Paolo Amadini
Sebastian Hengst
Nico Grunbaum
bechen
Gerald Squelart
Shing Lyu
Chris Pearce
Andreas Farre
Mats Palmgren
Peter Van der Beken
Eden Chuang
Stone Shih
David Parks
Olli Pettay
Samuel Vargas
Nicolas B. Pierron
Bill McCloskey
Garvan Keeley
Luke Wagner
Chun-Min Chang
Yoshi Huang
Timothy Nikkel
Daosheng Mu
Alfredo Yang
Ron Waisberg
Mike Conley
Alex Chronopoulos
Georg Fritzsche
Axel Nennker
Ting-Yu Chou
Wes Kocher