This will allow to remove mFrames member and calculate from the size of the content, which will dynamically change depending on a cropping filter.
Differential Revision: https://phabricator.services.mozilla.com/D20165
--HG--
extra : moz-landing-system : lando
If the AudioContext is suspended by content or by Autoplay policy, it shouldn't be resumed by chrome.
Differential Revision: https://phabricator.services.mozilla.com/D19451
--HG--
extra : moz-landing-system : lando
Different nodes might have same AudioParam, so we shouldn't append same stream multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D19450
--HG--
extra : moz-landing-system : lando
This patch would try to start a blocked AudioContext when it creates a MediaStreamAudioSourceNode which has an active input stream or when a node's inactive stream becomes active, which means someone is feeding input data to AudioContext.
Therefore, we can do the similar thing like what we did for AudioScheduledSourceNode and MediaElementAudioSourceNode, to start AudioContext if current autoplay policy has allowed AudioContext to start.
Differential Revision: https://phabricator.services.mozilla.com/D18576
--HG--
extra : moz-landing-system : lando
The helper stream which is created by the AudioParam can't be directly got from the AudioNode, which means that we can't suspend/resume all streams related with the AudioNode.
Therefore, we should also append these streams when AudioContext requires all streams.
Differential Revision: https://phabricator.services.mozilla.com/D18296
--HG--
extra : moz-landing-system : lando
Clang 7 was making the pow => exp2 optimization for us, and for some reason clang 8 stopped doing so. This resulted in a surprisingly large regression in raptor numbers.
Differential Revision: https://phabricator.services.mozilla.com/D18148
--HG--
extra : moz-landing-system : lando
We would only start the AudioContext blocked by our autoplay policy, won't resume AudioContext which is suspended explictly by page.
Differential Revision: https://phabricator.services.mozilla.com/D16613
--HG--
extra : moz-landing-system : lando
In order to separate resume/suspend called from chrome and content side, we need to create new methods.
Differential Revision: https://phabricator.services.mozilla.com/D16612
--HG--
extra : moz-landing-system : lando
We would only start the AudioContext blocked by our autoplay policy, won't resume AudioContext which is suspended explictly by page.
Differential Revision: https://phabricator.services.mozilla.com/D16613
--HG--
extra : moz-landing-system : lando
In order to separate resume/suspend called from chrome and content side, we need to create new methods.
Differential Revision: https://phabricator.services.mozilla.com/D16612
--HG--
extra : moz-landing-system : lando
Although we don't define BUILD_ARM_NEON on aarch64 (bug 1303952), aarch64
supports NEON, so we should turn on NEON for AudioNodeEngine.
OpenMAX DL doesn't support aarch64 since we modify some codes. So FFTBlock.h
still use ARM32 only.
Also, MSVC cannot use arm_neon.h header, doesn't allow
`float32x4_t zero = {0, 0, 0, 0};` and throws compiler warning.
So we need some workarounds to use this on MSVC.
Differential Revision: https://phabricator.services.mozilla.com/D16278
--HG--
extra : moz-landing-system : lando
As setting `mSuspendCalled` is enough to prevent the stream from starting, we have no need to apply unnessary audio context operation to MSG. In addition, it can avoid incorrect AudioContext's state because of out of order resume/suspend operation (https://bugzilla.mozilla.org/show_bug.cgi?id=1285290).
Differential Revision: https://phabricator.services.mozilla.com/D15679
--HG--
extra : moz-landing-system : lando
If media element is used as a source for AudioContext, we would try to start AudioContext which was not allowed
to start when media element starts playing.
Differential Revision: https://phabricator.services.mozilla.com/D14593
--HG--
extra : moz-landing-system : lando
In order to call this method on other situations, rename it to 'StartBlockedAudioContextIfAllowed()'.
Differential Revision: https://phabricator.services.mozilla.com/D14592
--HG--
extra : moz-landing-system : lando
'mWasAllowedToStart' would be set to false if AudioContext is not allowed to start, and would be set to true if AudioContext has been allowed to start.
Differential Revision: https://phabricator.services.mozilla.com/D14636
--HG--
extra : moz-landing-system : lando
Wrap 'nsContentUtils::ReportToConsole()' to reduce necessary input parameters and call it when we need to log error or warning message. Show the warning when autoplay is blocked.
For web audio, this restores the console messages removed in part4 and also reports the same message when the AudioContext is blocked in the constructor.
Differential Revision: https://phabricator.services.mozilla.com/D14330
--HG--
extra : moz-landing-system : lando
AudioContext won't need to ask permission request anymore, and we will report error message in patch5.
Differential Revision: https://phabricator.services.mozilla.com/D14329
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.