PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
This is a re-land of 9900d421e24e, which was backed out.
r=qdot,haik
MozReview-Commit-ID: FjugGCVWS8T
--HG--
extra : rebase_source : 7913a74a7bac9df09f8fc8e923384b5ac2569400
Because ProfilerMarkerPayload is the main type defined in these files, and
because the next patch is going to introduce ProfilerMarker.{h,cpp}, which
would be confusingly similar to the old names.
--HG--
rename : tools/profiler/core/ProfilerMarkers.cpp => tools/profiler/core/ProfilerMarkerPayload.cpp
rename : tools/profiler/public/ProfilerMarkers.h => tools/profiler/public/ProfilerMarkerPayload.h
extra : rebase_source : df22a2ab3867650348ae78fe959ff0366aff230b
When firing an event, check if there is any event in the delayed events queue,
if yes, fire them first to ensure the events are fired in the right order.
MozReview-Commit-ID: DY842oiHcVJ
The simulcast mochitests setup the receiving PeerConnection to receive
simulcast video streams which Firefox doesn't really support. Without
a test media server, this is about the best we can do and still test
simulcast.
Unfortunately the two simulcast streams arriving with different ssrcs
(as expect) exercises code we have to deal with some services switching
ssrcs midstream. In the tests, this causes intermittent failures
because the test is waiting to receive a certain ssrc, and the receiving
VideoConduit has switched to the other ssrc.
This change adds the ability to filter on RID at the MediaPipeline level,
which we can setup prior to media flowing. This avoids the ssrc switching
issue since the VideoConduit only receives one ssrc until we change the
RID filter to the second RID. At that point, the VideoConduit sees a new
ssrc and the switching code works as intended.
The modified mochitests setup the RTP stream id header extension, and then
filter on each of the RTP stream ids in turn.
MozReview-Commit-ID: KApfaxMX8rl
--HG--
extra : rebase_source : d7ae88d9675acd7b3700f342ca6a68d0bbb0ced5
The simulcast mochitests exhibit an intermittent failure due to ssrc-based
filtering that can be solved by filtering by RID. The RTP header parser
used in MediaPipeline also needs to have the RID RTP header extension
specified in order for it to properly parse the RTP header and allow
filtering on RID.
MozReview-Commit-ID: E54HCGLVYDk
--HG--
extra : rebase_source : b53085f23cb6558611aa7622f55637e19439c9c3
Discussion at <https://github.com/whatwg/dom/issues/319>. In short, the
specification used to say to throw sometimes InvalidCharacterError and
sometimes NamespaceError, but browsers disagreed on which to throw in
corner cases, and everyone agreed it wasn't worth the effort to spec the
distinction, so we just changed it to InvalidCharacterError across the
board.
The test changes are already upstream.
MozReview-Commit-ID: AWSZBznQprG
--HG--
extra : rebase_source : 2f0051f48124380f17300a38ceb8c2ab23015ca1
The APZ scrolling codepath doesn't do the right thing for <listbox>
without special handling, so have it scroll in JS instead, like we
did in bug 1302736 for <tree>.
MozReview-Commit-ID: LWJCBfhZ3Hc
--HG--
extra : rebase_source : bb8b2f7e713d35822a956e08f4e0eed0557b07b3
The EME spec requires EME to be only usuable from a secure context, for example
from an origin served over HTTPS. We still don't enforce this, and Chrome is
going to start enforcing this in M58. So to inform our decision as to when to
start enforcing this, it would be useful to know how many sites we'd break if
we started enforcing this.
So this patch adds telemetry to tell us the how often EME is used on secure
and non-secure contexts.
MozReview-Commit-ID: BKS5iY4V3wK
--HG--
extra : rebase_source : 77b98516e0d8a0471f8c7a1e5bf54bcf9f74b7da
Currently, attribute and child arrays (implemented in dom/base/nsAttrAndChildArray.h) start out empty. When cloning, the array ends up being resized multiple times in order to add the attributes and children that are being cloned from the original node. This would be quicker if the array was initialized to the correct size in the first place so that resizes are not necessary.
However, preallocating space for children is only necessary when performing a deep clone. Therefore, an additional parameter is being added to the Clone, CopyInnerTo, and CloneDocHelper methods to indicate whether preallocation of children should happen. Attributes are copied either way, so that part of the array is preallocated in both cases.
MozReview-Commit-ID: 3iVezeAKXnI
--HG--
extra : rebase_source : 9c3deec6d7aafd6411044d623d4863637b45fd58
It turns out that sync notification is a bad idea which is easy
to be misused and could results in unexpected reentrant call flow.
Since it has no users after the mass media code refactoring, it is
good to remove it now to prevent future users.
Backed out changeset fb5b05298007
Backed out changeset 9e1fb308cf51
MozReview-Commit-ID: 9WGvRCbvJhQ
--HG--
extra : rebase_source : 748cae9449636c68f3fffbaed0e08347fe63cd91
XPCJSContext::Get() now does a TLS lookup, which is a little more expensive
than looking up a global variable. This patch removes as many of the TLS
lookups as possible.
MozReview-Commit-ID: GsqzJn55Lya
The ChromiumCDMParent is informed of the shutdown of its plugin, so we can
use that to inform the CDMProxy that its connection to the CDM has been
severed. This means we shutdown cleanly if the browser closes while playing.
MozReview-Commit-ID: HphQ2exu1gj
--HG--
extra : rebase_source : ff9ee3699915e8b7527570e839eb3bb0a0ab46bc
We are pre-allocating shmems in the content process for use by the CDM in the
GMP process. We guess the size of shmem required. However if we guess wrong,
currently we always end up taking the non-shmem path for video frames to
return to the content process, which results in us sending another shmem
(of the wrong size) to the CDM, and this continues until we hit the limit
on the number of shmems that we tolerate the CDM asking for.
So in this patch, I change our behaviour to detect when we're allocating
shmems that are too small, whereupon we purge the existing shmems and switch
to allocating them at the size being requested by the CDM.
This means we recover from incorrectly guessing the size of shmems required
by the CDM. The overhead of an incorrect guess should be one video frame
transferred via the nsTArray path.
MozReview-Commit-ID: 8o1s7FI2UBd
--HG--
extra : rebase_source : 0612d199686278612e8c58dc97e96a9304ea3ee9
When profiling nsDocumentEncoder::EncodeToStringWithMaxLength for text/plain, 25% is Preferences::GetBool into nsPlainTextSerializer::Init. So we should use AddBoolVarCache for it.
MozReview-Commit-ID: 9CVd4OZzzr5
--HG--
extra : rebase_source : 6b860927b64109ae41a07a161f47612df2f176b7
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
--HG--
extra : rebase_source : 4b29b859aa5745fabe3db0fe68742328fc0af175
