This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
This splits out the inner bit of RecvEmptyTransaction to just iterate over
the documents once, rather than iterating over them individually. Originally
I ran into difficulties with this and then left it on the table, but I think
it was enabled by splitting out the epochs in pipeline info by renderroot.
Differential Revision: https://phabricator.services.mozilla.com/D35123
--HG--
extra : moz-landing-system : lando
I needed empty blobs in MediaRecorder and seeing that there was no
Blob::CreateEmptyBlob, nor an export of EmptyBlobImpl, I thought
Blob::CreateEmptyBlob would be the cleaner solution, so here it is.
Differential Revision: https://phabricator.services.mozilla.com/D35310
--HG--
extra : moz-landing-system : lando
This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D17813
--HG--
extra : moz-landing-system : lando
This first of all does some refactoring of how metadata is encoded in
MediaEncoder. This is now guided by the new Muxer class. If we're ready to pass
data to the muxer and it does not have metadata yet, we provide metadata before
giving it any media data. This metadata is passed to the muxer in a single call.
The metadata provided in this call must stay valid for the entire recording.
This removes MediaEncoder::GetEncodedMetadata().
This also removes the ctor argument from the WebMWriter since it can now rely on
the single SetMetadata() instead.
To comply with the ContainerWriter::SetMetadata() docs,
WebMWriter::SetMetadata() will now also sanity check metadata.
ContainerWriter instances are updated somewhat, to accommodate these changes.
Lastly, and most important, the new Muxer class manages muxing of the (up to)
two tracks into a single container, ensuring that timestamps increase
monotonically throughout a recording.
Differential Revision: https://phabricator.services.mozilla.com/D35306
--HG--
extra : moz-landing-system : lando
Update MediaEncoder to pass frames to the muxer in order of their time stamps.
This should prevent the currently possible scenario where audio and video
frames are written with non-monotonically increasing timestamps (in violation
of the webm spec).
Differential Revision: https://phabricator.services.mozilla.com/D35388
--HG--
extra : moz-landing-system : lando
MediaQueue provides a better interface for interleaving frames when writing to
the muxer (this change will follow in another changeset). The queue interface
provides a nicer abstraction than manually managing a nsTArray.
MozReview-Commit-ID: 5V5XmYODFdA
Differential Revision: https://phabricator.services.mozilla.com/D35387
--HG--
extra : moz-landing-system : lando
This changes EncodedFrame to behave more like MediaData, so that EncodedFrame
can be used with the MediaQueue data structure. It also provides a somewhat
more consistent interface across media data types.
MozReview-Commit-ID: I2o6n30ErxB
Differential Revision: https://phabricator.services.mozilla.com/D35386
--HG--
extra : moz-landing-system : lando
Move the responsibility of adjusting opus frame timestamps to the MediaEncoder.
This was previously done by the EbmlComposer, but doing so in the MediaEncoder
means we can have greater control over handling of time codes and interleaving
of frames.
MozReview-Commit-ID: 2g9cy1IqOph
Differential Revision: https://phabricator.services.mozilla.com/D35385
--HG--
extra : moz-landing-system : lando
Remove EncodedFrameContainer and clean up areas where it was used.
EncodedFrameContainer provided a wrapper around an
nsTArray<RefPtr<EncodedFrame>>, but it simplifies the code to simply expose
this array. Also clean up unused enums in EncodedFrame, and clean up some of
the outdated comments for our encoded frame handling.
MozReview-Commit-ID: Bh3VKesVoJE
Differential Revision: https://phabricator.services.mozilla.com/D35384
--HG--
rename : dom/media/encoder/EncodedFrameContainer.h => dom/media/encoder/EncodedFrame.h
extra : moz-landing-system : lando
Separating the encode and mux steps allows for better control over interleaving
audio and video data. If encode and mux are done in a single step it's possible
to mux large amounts of audio or video data which should have been interleaved
with the other data type to give correctly ordered time stamps in the target
container.
MozReview-Commit-ID: CBYemrkpyF5
Differential Revision: https://phabricator.services.mozilla.com/D35383
--HG--
extra : moz-landing-system : lando
This minimizes regret by requiring T: Copy and switches
to read_unaligned() because the pointer can be unaligned.
Differential Revision: https://phabricator.services.mozilla.com/D37861
--HG--
extra : moz-landing-system : lando
Because ShouldIncludeEdge considers the |origin| node as well, it was possible for
the old code to 'miss' nodes and never write them to the core dump even though we
also wrote some edges with the node as referent.
Differential Revision: https://phabricator.services.mozilla.com/D37701
--HG--
extra : moz-landing-system : lando
There's currently a bug in Android's framework that manifests by placing the
floating menu off-screen if a menu label overflows the menu's width.
https://issuetracker.google.com/issues/137169336
To overcome this we'll manually check and truncate any menu label that could
cause issues based on the floating menu style declared upstream.
Differential Revision: https://phabricator.services.mozilla.com/D37684
--HG--
extra : moz-landing-system : lando
We shouldn't perform an anti-tracking check here, since that may result
in us picking the node principal unintentionally.
Differential Revision: https://phabricator.services.mozilla.com/D37811
--HG--
extra : moz-landing-system : lando
XDR should be a structural clone, so check if we have a lazy script
directly when deciding if it should be coded. Whether relazification
should be supported is a VM decision, not an XDR decision. This gives a
cleaner round-trip of data when using XDR.
Differential Revision: https://phabricator.services.mozilla.com/D37578
--HG--
extra : moz-landing-system : lando
This is a pretty big change on paper, but most of the lines are copy-pasted, with some small
adjustments to get the content blocking code comfortable in browser-siteProtections.js.
Differential Revision: https://phabricator.services.mozilla.com/D37556
--HG--
extra : moz-landing-system : lando
This lives in the protections popup now and will get a new probe.
Since I'm only removing data collection I don't think a data steward is required to sign off.
I'm removing recordClick calls in identityPanel.inc.xul in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D37555
--HG--
extra : moz-landing-system : lando
When Firefox is configured to resist fingerprinting, the latency figure returned
is the most commonly found on a particular OS.
For Android, I got data from [0], roughly copy/pasted the table into a file and
did:
```
cat file | cut -d $'\t' -f4 | grep "^[[:digit:]]" | cut -d ' ' -f 1 | sort -h
| uniq -c | sort -h
```
which indicated that 40ms was a good number for round trip latency (input to
output). Since this is for output latency only and the audio path
is roughly symmetrical in terms of duration, we report 20ms.
For OSX, 512 is always used with the default hardware in Firefox, with this
patch, it's always 512 regardless of the setup.
On Linux/Pulse, we use 25ms [1] always, and this is adjusted by PulseAudio. This
makes it always return 25ms.
On Windows, there is a wide variety of configurations, but it's common to be in
the ballpark of 80ms output (this is very empirical, by testing a bunch of
hardware over the years).
For other OSes, we use 2048 frames (adjusted to the sample-rate).
[0]: https://superpowered.com/latency
[1]: https://searchfox.org/mozilla-central/source/media/libcubeb/src/cubeb_pulse.c#725
Differential Revision: https://phabricator.services.mozilla.com/D37723
--HG--
extra : moz-landing-system : lando
