(EnterVideoSuspend/ExitVideoSuspend) event pair and (VideoOnlySeekBegin/VideoOnlySeekCompleted) event pair should not interleave each other.
MozReview-Commit-ID: HehMIls11nc
--HG--
extra : rebase_source : a667443b60524853c76b2a5155f45ae289a4be5b
This allows us to save copies in combining 2 bufffers into one before calling
FileBlockCache::WriteBlock().
MozReview-Commit-ID: 62kQIxp3Ju0
--HG--
extra : rebase_source : a64c160b9ab3d7bbd724be053fea6358ae7885df
extra : source : f699fdb6fdaf1fd5b4dfeb394928c95e33853a53
The spec for canvas drawImage says to use the first frame. I can't find anything spec related at all referencing the issue for webgl (except bug 666855). So do the same as drawImage.
We don't currently support H.264 on Android in automation, but we can improve
our test coverage by running the VP8 portion of this test in the meantime.
MozReview-Commit-ID: 3SPCTaqlfMk
--HG--
extra : rebase_source : cae3251f489e45f56b04378074083d6b4fd24666
Process the arguments of "MethodGroup" and "MethodGroupCollapsed"
Use the result of ProcessArguments to compute the groupName so we can get
rid of the "%c" parts.
MozReview-Commit-ID: 5B2jqG5RoRj
--HG--
extra : rebase_source : 256ef1ffc80157751cb202cc163cb2ca42c7397a
Our caller is C++ code, and the implementations are all also written in C++,
so there is no reason to go through SpiderMonkey here. This patch also makes
nsILoadContext builtinclass to ensure that the implementation is always native.
This happens when the listener and a PannerNode are at the same position, and
a cone gain has been specified.
The issue is that our implementation of 3d vector normalization does not
special-case vectors that have all components at zero, that dividing by zero
results in infinity, and multiplying by infinity produces NaN.
This end up setting the volume member for the output AudioChunk to NaN, and this
breaks everything downstream, of course. In practice, silence is output, with
some clicks (on linux/pulse at least).
MozReview-Commit-ID: 8u54LixvYMu
--HG--
extra : rebase_source : 3b37970b42e5c60cd6e39d3197b580edc63b5ac9
We know these rewritable YouTube Flash embeds are out there. We don't need to track that we're rewriting them. While only about 0.4% of browser sessions saw rewritable embeds in April 2017, compared to almost 2% in April 2016, is there any reason we would decide to stop rewriting these embeds?
If YouTube ever stops serving Flash video entirely, then we should remove the enablejsapi check (YOUTUBE_NONREWRITABLE_EMBED_SEEN) so users at least see a non-scriptable video instead of nothing.
MozReview-Commit-ID: IixKc6myvs6
--HG--
extra : rebase_source : f1f9f7ea9cffc585f95ff83dbeedd734e0b83cc3
Firefox 51 users with telemetry enabled blocked about 4.35M SWFs for stability. The block count has been in the single-digit millions for the last few releases. We don't expect these SWFs to go away, so we can stop tracking this telemetry and later replace this plugin blocklist with a more general solution.
MozReview-Commit-ID: KF1jIBTG5m4
--HG--
extra : rebase_source : 5dbdfadfed4f88da33fb4f2efc66c7dd1777b2b3
