This disables the outdated, incorrect implementation of the
Reporting API. The current implementation was only enabled
on Nightly builds, but given its current state it does not
even make sense there.
Differential Revision: https://phabricator.services.mozilla.com/D149873
Make mozSubdialogReady properly wait for async initialization, remove no longer
necessary resize listener (since the dialog is not resizable anymore), and
simplify the mutation observer.
Differential Revision: https://phabricator.services.mozilla.com/D161791
Considering the difficulty to figure out what's going wrong because none
of members of the build team can reproduce this, and considering that
the problem bug 1791476 addresses only affects TSAN for the moment, and
TSAN is not supported on Windows, let's just go back to what the linker
wrapper was before bug 1791476 on Windows, which will at least unblock
people.
We'll eventually have to figure out what's going wrong, but that's for
another day.
Differential Revision: https://phabricator.services.mozilla.com/D162179
On POSIX platforms there can be `lib` and `lib64` for `site-packages`.
On Fedora35 once a virtualenv is created, `lib64` is a symlink of `lib`.
Since we can determine what these paths will be before the virtualenv is
created, `realpath` has different results before/after, which is
problematic for our `pthfile`.
Since we only care about resolving the symlink in the prefix (to keep it
in line with the `topobjdir`, we can simply only `realpath` that and
disregard that there's a symlink between `lib` and `lib64`, which makes
our `pthfile` that's created and expected always the same on all
platforms.
Differential Revision: https://phabricator.services.mozilla.com/D162136
This needs to change `nsContentUtils` methods because of used by the method.
Then, we can make some there callers are also `const` methods.
Depends on D162065
Differential Revision: https://phabricator.services.mozilla.com/D162066
Most of them are used only by the WebIDL bindings. Therefore, this fixes only
one caller in `HTMLEditUtils`.
`GetText` requires to change `nsContentUtils`, therefore it'll be done by the
following patch.
Differential Revision: https://phabricator.services.mozilla.com/D162065
Webrender uses this flag as a hint to separate mix blend containers so it should only be present on the root content document.
Differential Revision: https://phabricator.services.mozilla.com/D162046
Currently this doesn't take account of the fact that gray bits may not be
corrent during incremental GC. The provided API function handles this.
Differential Revision: https://phabricator.services.mozilla.com/D162099
be -> 4e470f47b18f6ae326c89f885b45bed7c3f979ac
da -> 518aaf9ab72d9c6c60817292bfd388f2a8b2747b
fi -> f7c89d63171aa6a20df64c7bf5210ecce85258ea
gn -> d29869a0f58e48c947e9f672d2d33fcfc7aa4c34
hsb -> 182a7e5c9858392e1dc95f0882d9755128da6993
it -> 0d09be56b521e37ea9a48bea452541b2b8855220
kk -> 92df8e4f4476d7c0744f51e3f6ab55e999d295fa
lo -> 23d8adc00cead30153717bcbb7d274847bec34f5
pt-PT -> c570bea2b629b5f7971e712a8c69dbd5491b1002
tg -> b0f606d88f3882aa14e01bcc12f53530e961951e
We had a number of tests that assumed that when adding a browser_action without
specifying the default_area, that the button would enter the navbar. The previous
patch in this series changes that assumption when the Unified Extensions UI is
enabled.
Instead of updating all of these tests to add additional steps to move the
browser_action's out to the navbar after adding them, I've gone ahead and
updated them to default their browser_action's to the navbar instead.
Differential Revision: https://phabricator.services.mozilla.com/D161721
This patch fixes the incorrect condition for the single track playback,
because the EOS flag for the nonexistent track would always be true.
Eg. for audio-only playback, `mIsReachingVideoEOS` is always true.
Differential Revision: https://phabricator.services.mozilla.com/D162025
