When playback starts, currentTime is always 0, and even if the buffered data doesn't contain currentTime it is possible for playback to progress as we always allow up to 500ms gap in the buffered data.
As such, we must use fuzzing on the interval's start time when determining if we have future data.
MozReview-Commit-ID: Ki9QxmKhfdY
--HG--
extra : rebase_source : b7a550348b61d96f91e73b171a5dd03b16a4c152
Similar to test_PlayEventsAutoPlaying.html, but here we load 10s of data and ensure autoplaying kicks in.
MozReview-Commit-ID: ImpjFIcBIo1
--HG--
extra : rebase_source : c7d280eebeb6b3398176423b9e723696c9543c7f
We want to avoid to have several cached content processes, one for each
preloaded browser (one per window) and one for the preallocated process.
For that we force the preloaded browser to choose an existing process and
during the first navigation in that tab, that leaves about:newtab, we re-run
the process selecting algorithm
nsIIOService based events when used via SpecialPowers in mochitests
combined with the preloaded browser in the same process can cause
IsSafeToRun() assertion in SchedulerGroup.h:81. To avoid that we make sure that
previous tests in the suit do not create a preloaded browser. This cannot happen
in a real life scenario.
This gets us coverage for anonymous nodes, which are currently missed.
MozReview-Commit-ID: KBOSXloteu6
--HG--
extra : rebase_source : 0f71c027f8bbbb0abd4d9e812b5d7369109e7ebc
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
--HG--
extra : rebase_source : e68befcde4dd098bac2a550bc666eaf3bf1298d7
Despite the comment, this was necessary only for a direct convolver stage,
which has been removed:
https://hg.mozilla.org/mozilla-central/rev/e66105937eef190dec073f1b9859e07a0272706b#l4.29
FFT convolver stages pad the buffer to the necessary length in
FFTBlock::PadAndMakeScaledDFT().
Trailing zeros in the impulse change the scale used in normalization
and so padding the buffer before calculating the scale led to the wrong scale
being used.
https://github.com/WebAudio/web-audio-api/issues/481
MozReview-Commit-ID: LqP1x1hmLOM
--HG--
extra : rebase_source : f902190c25a7b95594d8115e43cde91f0cf00146
BHRTelemetryService only runs in the parent process (and we can only submit
pings from there), so we need to send the data which we collect in the GPU and
Content processes over IPC to the parent process.
MozReview-Commit-ID: 8B5uZKbjNbU
Our current machinery for enabling stylo requires a docshell - if there isn't
one, we default to the Gecko style system.
When getComputedStyle operates on an element without a presshell, it uses the
caller's presshell instead. If the element has previously been styled with
one style system (but no longer has a presshell), and the caller uses a
different style backend, using the caller's style system can cause crashes when
we pull bits of cached data off the DOM (like cached style attributes).
So we want to throw when window.getComputedStyle(element) is called for a
(window, element) pair with different style backends (which is what the next
patch in this bug does).
However, that causes a few failures where stylo-backed documents try to do
getComputedStyle on an XHR document (which, without a docshell, will use the
gecko style system).
So this patch does some work to propagate the creator's style backend into
various docshell-less documents. This should allow both chrome (which uses gecko)
and content (which uses stylo) to use getComputedStyle on the response document
for XHRs they create.
Note that the second patch in this bug will make
chromeWin.getComputedStyle(contentObj) throw. If we discover code that does
that, we can just make it invoke the content's getComputedStyle method over Xrays.
MozReview-Commit-ID: 5OsmHJKq5Ui
