Rules and their declarations are a single object as far as the CC is concerned. They have a single nsCycleCollectionISupports and they are represented by a single node in the CC graph. That single object has two nsWrapperCache instances in it that point to different JS objects, and we need to make sure that the ordering of the unlink operations for those nsWrapperCache instances is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D38326
--HG--
extra : moz-landing-system : lando
Fall back to using Google's DNS server to determine the associated local
addresses for web applications that are not loaded over the network. This
includes the loopback address, which is frequently used in the unit tests.
Provide a separate function for setting the target for the default local
address lookup.
Differential Revision: https://phabricator.services.mozilla.com/D37331
--HG--
extra : moz-landing-system : lando
draft-ietf-rtcweb-ip-handling specifies that the default route is the route
used to reach the origin rather than the one used to reach the internet, so
update the IP routing to reflect this. This addresses issues in which the
wrong IP address is used on machines with multiple network interfaces.
Differential Revision: https://phabricator.services.mozilla.com/D36831
--HG--
extra : moz-landing-system : lando
The crash appears to be being caused by the GetEmbedderWindowGlobal call
returning a null value. This patch simply avoids the crash in this case, and
returns a reasonable default value of false, as it should never be true for a
BrowsingContext with a parent without Fission enabled.
This patch should be small enough to safely uplift if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D38722
--HG--
extra : moz-landing-system : lando
When a test crashes, the harness skips all of the remaining tests in the
directory. That means that with crashes skipped, we now try to run a whole lot
more tests than we did before, and a lot of them fail under Fission.
This patch adds annotations to the new failures that show up after part 1.
Differential Revision: https://phabricator.services.mozilla.com/D38726
--HG--
extra : rebase_source : 292157039c88fc615f5de41679e96e72766ac4db
This makes the underscore sort after letters, which works around tacit
assumption that such custom headers don't sort to the beginning of the
string.
Differential Revision: https://phabricator.services.mozilla.com/D31786
--HG--
extra : moz-landing-system : lando
Unmasking is an optional style of showing password. Therefore, if callers of
`nsIEditor::Unmask()` specify middle of surrogate pair(s), it may mean that
they want to expand the unmask range from shorter range which does not include
the high and/or low surrogate. Therefore, one of the surrogates is in unmasked
range, we unmask the surrogate pair. However, we handle this in a lot of
places, i..e., we have duplicated code. This can get rid of these duplicates
with making `nsIEditor::Unmask()` expand the range automatically.
Differential Revision: https://phabricator.services.mozilla.com/D38432
--HG--
extra : moz-landing-system : lando
In some cases, other tools may show selected content in their UI. E.g.,
character palette of macOS. Therefore, we shouldn't allow them to show
masked password.
Differential Revision: https://phabricator.services.mozilla.com/D38430
--HG--
extra : moz-landing-system : lando
Now, the anonymous text node has raw value of password so that we shouldn't
allow users to drag the text since another user may have typed the password
and left from the device.
Note that we've supported the operation, however, it does not make sense
since the dragging data is masked text.
Additionally, Chrome also doesn't support dragging text in password fields.
So, we have no reason to support dragging raw value from password fields.
Differential Revision: https://phabricator.services.mozilla.com/D38012
--HG--
extra : moz-landing-system : lando
This method makes the following patches simpler and avoid duplicating same
code.
The utility method retrieves `TextEditor` from `HTMLInputElement` and
`HTMLTextAreaElement`. However, this won't cause creating corresponding
editor because when it calls from `TextEditor`, editor shouldn't be created
at that time due to requiring another reflow. Additionally, it's not
necessary for `nsTextFrame` because without `TextEditor`, all characters
in password field should be masked.
Differential Revision: https://phabricator.services.mozilla.com/D38008
--HG--
extra : moz-landing-system : lando
With the previous patches, editor has stopped masking characters in password
field. Instead, layout code needs to handle it. However, layout code
especially around `nsTextFrame` is performance critical area. Therefore,
layout code requires a quick way to check whether a text node in password
field or not.
This patch creates new flag for `CharacterData` node and marks all text nodes
whose characters should be masked with the flag when `EditorBase` or
`nsTextControlFrame` creates them.
Differential Revision: https://phabricator.services.mozilla.com/D38006
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
This is a potential fix that I thought it was worth doing rather than
implementing Blink's platform-dependent silliness. This ensures that the display
frame always has enough space to display itself.
Note that it may still get clipped, if there's no room for both the display
frame and the button.
Differential Revision: https://phabricator.services.mozilla.com/D37922
--HG--
extra : moz-landing-system : lando
ECMA-402 changed the language tag specification from RFC-5646 BCP-47 language
tags to UTS 35 Unicode BCP-47 locale identifiers. Update the expected
canonicalisation results accordingly.
Depends on D37450
Differential Revision: https://phabricator.services.mozilla.com/D38642
--HG--
extra : moz-landing-system : lando
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
If an mp4 uses the AVC3 sample format then extra data will be stored in sample
data rather than in metadata. In encrypted streams the metadata is unencrypted
but samples are typically encrypted. If all samples are encrypted and the only
SPS data is in samples then the MediaChangeMonitor will never observe any SPS
data.
This updates the MediaChangeMonitor so that it will not try and inspect h264
content once encryption is detected and relies on the CDM to handle such
content.
Differential Revision: https://phabricator.services.mozilla.com/D37485
--HG--
extra : moz-landing-system : lando
Adds a lock in MediaCacheStream::SizeOfExcludingThis to prevent a race
condition with MediaCache::NoteSeek
Differential Revision: https://phabricator.services.mozilla.com/D36880
--HG--
extra : moz-landing-system : lando
In bug 1552607/D36382, RemoteDataDecoder always increases session ID but
CodecProxy only performs flush IPC when neccessary. This will cause the
ID numbers out of sync and prevent remote decoder from receiving any
more input. By reading the session ID in dequeued input samples, the
numbers can always be in sync.
Differential Revision: https://phabricator.services.mozilla.com/D37123
--HG--
extra : moz-landing-system : lando
Having to namespace these into GeckoChildProcessHost is annoying. The
|using| declarations help to some extent, but it's easier to just put
them in mozilla::ipc.
Differential Revision: https://phabricator.services.mozilla.com/D36538
--HG--
extra : moz-landing-system : lando
Depending on the timing of events, we can invoke InitInternal after
we've already torn down the compositor thread, which can make
CreateContentBridges fail, which in turn makes us unable to make a
correct InitRendering call. Implement the infrastructure to bail out in
this case.
Differential Revision: https://phabricator.services.mozilla.com/D36644
--HG--
extra : moz-landing-system : lando
This allows us to create profiler markers whose description contains the name
of the function and its file / line number. This allows the profiler UI to
match up setTimeout callbacks for multiple instances of the same page load, in
order to create meaningful profile comparisons based on markers.
Differential Revision: https://phabricator.services.mozilla.com/D19192
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
Nika Layzell
Boris Zbarsky
Ciure Andrei
Bobby Holley
Emilio Cobos Álvarez
Sean Feng
Ryan Alderete
Byron Campen [:bwc]
Sebastian Streich
Christian Holler
Daniel Varga
Kris Maglione
Henri Sivonen
Masayuki Nakano
Nicholas Nethercote
Jean-Yves Avenard
Eugen Sawin
Andreas Pehrson
Kashav Madan
André Bargull
Gurzau Raul
Thomas Nguyen
Edwin Gao
Oana Pop Rus
Brindusan Cristian
Olli Pettay
alwu
Christoph Kerschbaumer
Mike Conley
Andrew McCreight
Tom Ritter
Noemi Erli
Cosmin Sabou
M. Sirringhaus
Marcos Cáceres
Mirko Brodesser
Jan-Ivar Bruaroey
Matt Woodrow
Razvan Maries
Karl Tomlinson
Ryan Hunt
Mihai Alexandru Michis
soniasingla
longsonr
Niklas Hambüchen
Andrea Marchesini
Andreea Pavel
Dorel Luca
Jon Coppeard
Bryce Van Dyk
Gijs Kruitbosch
Ehsan Akhgari
Paul Adenot
Jan Andre Ikenmeyer
Csoregi Natalia
Michael Froman
Tom Schuster
shindli
Jeff Gilbert
Tarek Ziadé
Alphan Chen
Kagami Sascha Rosylight
John Lin
Agi Sferro
Will Hawkins
arthur.iakab
Markus Stange
Brendan Dahl
Barret Rennie