This is the safer assumption, since we normally skip setting isTopFrame
explicitly if no BrowsingContext exists (which is the case if, for example,
the crash is due to the fact that creating the top-level browser failed).
Differential Revision: https://phabricator.services.mozilla.com/D38119
--HG--
extra : moz-landing-system : lando
When a BrowsingContext changes from being local to remote, we have to
change all window proxies from being local to remote, using
transplanting. The actual window proxy becomes a remote window
proxy. Cross compartment wrappers (CCWs) to the window proxy also
become remote window proxies in their respective compartments, rather
than CCWs to a remote proxy in the old compartment of the window
proxy, because the window is no longer actually in that
compartment. This also avoids having to figure out what Xray behavior
for remote window proxies should be.
This patch uses the transplanting support I added to
GetRemoteOuterWindowProxy() in the previous patch to ensure that the
remote proxy map holds the correct value after transplanting finishes.
It drops the requirement that both arguments to JS_TransplantObject
have the same class, because we need to transplant a window proxy with
a remote window proxy. It also deals with this by not adding origobj
to the wrapper map unless it is a CCW, to handle transplanting to a
remote proxy.
The core design here, with the remote window proxies in every
compartment, is taken from a patch by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D35730
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
When a BrowsingContext changes from being local to remote, we have to
change all window proxies from being local to remote, using
transplanting. The actual window proxy becomes a remote window
proxy. Cross compartment wrappers (CCWs) to the window proxy also
become remote window proxies in their respective compartments, rather
than CCWs to a remote proxy in the old compartment of the window
proxy, because the window is no longer actually in that
compartment. This also avoids having to figure out what Xray behavior
for remote window proxies should be.
This patch uses the transplanting support I added to
GetRemoteOuterWindowProxy() in the previous patch to ensure that the
remote proxy map holds the correct value after transplanting finishes.
It drops the requirement that both arguments to JS_TransplantObject
have the same class, because we need to transplant a window proxy with
a remote window proxy. It also deals with this by not adding origobj
to the wrapper map unless it is a CCW, to handle transplanting to a
remote proxy.
The core design here, with the remote window proxies in every
compartment, is taken from a patch by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D35730
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
Preferences::GetBool is not thread-safe, StaticPrefs are.
Also StaticPrefs are nicer anyway.
There's a lot of Preferences:: usage in dom/media which looks suspicious, though
I don't know if all that runs on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D38097
--HG--
extra : moz-landing-system : lando
Make Firefox not assume type of member statvfs::f_frsize from sys head, which may vary
Differential Revision: https://phabricator.services.mozilla.com/D38306
--HG--
extra : moz-landing-system : lando
Minor things to ease the transition to StaticPrefList.yaml.
- Rename apz_touch_drag_enabled() to the correct apz_drag_touch_enabled(), and
media_mwf_low_latency_force_disabled() to the correct
media_wmf_low_latency_force_disabled().
- Change some trailing C-style comments to C++-style comments. This makes life
easier for the script I wrote to convert StaticPrefList.h to
StaticPrefList.yaml, which will be used for the next patch.
- Avoid comments on #define lines, because they aren't handled in the YAML
input.
- Convert a multi-line `#if` condition to a single line, because
Preprocessor.py doesn't handle multi-line conditions.
- Remove one unnecessary `#undef PREF_VALUE` directive.
- Move intl.charset.detector.iso2022jp.allowed to the correct section, so the
YAML processing script won't complain.
- Change an `int` pref to `int32_t`, again so the YAML processing script won't
complain.
- Change OS_OPENBSD to XP_OPENBSD, because the former isn't defined for
preprocessor.py. (It's also only defined in C/C++ when chromium-config.h is
included, which isn't always the case.)
Differential Revision: https://phabricator.services.mozilla.com/D37815
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
Direct use of aInput buffers for ArrayBuffer elements is not possible in
general. aInput buffers are const because they may be used elsewhere but
ArrayBuffer elements may be modified by script. If necessary, it would be
possible to later add a mechanism to mix inputs directly into the ArrayBuffer,
but often no mixing is required.
Direct use of output ArrayBuffer elements would require DetachArrayBuffer to
ensure the elements are not modified by script, but that would require
creation of a new ArrayBuffer JS object on each call.
https://github.com/WebAudio/web-audio-api/issues/1932 tracks specification of
making output data available for reading (for downstream node input).
Differential Revision: https://phabricator.services.mozilla.com/D34837
--HG--
extra : moz-landing-system : lando
The ipc::browser-destroyed message must be sent when a top-level remote browser is destroyed.
Currently this is done by BrowserParent::ActoryDestroy and relies on having access to
mBrowserHost. This can break if we start clearing out this pointer. This commit moves
the trigger to fire in BrowserHost::DestroyComplete. Semantically this is different,
but from the users of this observer, I don't see any risk.
Differential Revision: https://phabricator.services.mozilla.com/D37171
--HG--
extra : rebase_source : c863fb8d8a3a540d3dec42472c71342bed8ba541
extra : amend_source : aae3d054d453e63c10fec8707c8cda0497580a87
This ensures that the object is not discarded while there are still in-flight
messages from the parent process, and vice-versa, which could cause crashes if a
CC was run before any pending messages have arrived.
Differential Revision: https://phabricator.services.mozilla.com/D36995
--HG--
extra : moz-landing-system : lando
# ignore-this-changeset
These are all automatic changes via ESLint/prettier.
Differential Revision: https://phabricator.services.mozilla.com/D37978
--HG--
extra : moz-landing-system : lando
The previous error message suggested that this is an internal error message
pointing out a bad state in the XHR state machine, when in fact this is
a user error (calling `overrideMimeType()` or setting `responseType()` after
`send()`).
This commit improves and disambiguates the error messages, pointing out to
the user what they did wrong, like other browsers do.
Differential Revision: https://phabricator.services.mozilla.com/D37659
--HG--
extra : moz-landing-system : lando
The way we use `operator/` on TimeUnit is usaually to divide 2 for the fuzz or to divide the playback rate, and the rate is always a unsigned int.
The `operator%` should also have same constraint, because there is meaningless to do such a operation on a negative value.
Differential Revision: https://phabricator.services.mozilla.com/D37310
--HG--
extra : moz-landing-system : lando
This is a partial revert of bug 1524890 - P17.
When setting the duration, with some videos, on output WMF set nonsensical values. Sometimes the duration read is equal to the timestamp of the previous frame leading to broken A/V sync.
In bug 1222874, we will remove the entire concept of video frame's duration.
Differential Revision: https://phabricator.services.mozilla.com/D37683
--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
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
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
alwu
Thomas Nguyen
Christoph Kerschbaumer
Mike Conley
Andrew McCreight
Tom Ritter
Noemi Erli
Sebastian Streich
Emilio Cobos Álvarez
Cosmin Sabou
M. Sirringhaus
Ciure Andrei
Marcos Cáceres
Nicholas Nethercote
Kris Maglione
Daniel Varga
Mirko Brodesser
Gurzau Raul
Christian Holler
Jan-Ivar Bruaroey
Matt Woodrow
Razvan Maries
Karl Tomlinson
Ryan Hunt
Nika Layzell
Mihai Alexandru Michis
soniasingla
Kashav Madan
longsonr
Niklas Hambüchen
Andrea Marchesini
Jean-Yves Avenard
Andreea Pavel
Byron Campen [:bwc]
Dorel Luca
Jon Coppeard
Andreas Pehrson
Bryce Van Dyk
Gijs Kruitbosch
Ehsan Akhgari
Paul Adenot
Jan Andre Ikenmeyer