In order to support multiple API's (WebVR + WebXR) being enabled simultaneously, a new class, gfx::VRManagerEventObserver, implements a pure virtual interface to be shared by both the WebVR and WebXR observers of XR device related events.
Differential Revision: https://phabricator.services.mozilla.com/D39985
--HG--
extra : moz-landing-system : lando
This patch ressurects HiddenFrame.jsm and uses it when handling
the --screenshot command line argument to load the requested page
in a content process. The actual logic for grabbing the image is
also ported to a JSWindowActor. The test for this feature remains
suboptimal as described in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D40148
--HG--
rename : browser/components/shell/HeadlessShell.jsm => browser/components/shell/ScreenshotChild.jsm
extra : moz-landing-system : lando
The patch makes the code for handling screenshots in the driver and
listener module easier to understand. Also it sets the default values
for optional arguments once, which doesn't require duplicated code
for the listener anymore.
Further there was a bug which treated the "full" parameter with a
higher priority as an element, if both are defined.
Differential Revision: https://phabricator.services.mozilla.com/D40818
--HG--
extra : moz-landing-system : lando
This patch implements the MozPower class in the Mozpower module which is the interface for the user to use the power measurement tooling. It primarily detects the user's OS and CPU combination and provides the appropriate methods for them.
Differential Revision: https://phabricator.services.mozilla.com/D39194
--HG--
extra : moz-landing-system : lando
It was added in Firefox 44 and isn't checked
anywhere in the codebase, so we can safely
remove it.
Differential Revision: https://phabricator.services.mozilla.com/D40545
--HG--
extra : moz-landing-system : lando
There are now only two left:
- one for the OSX 10.11 SDK
- one for Visual Studio 2017
Differential Revision: https://phabricator.services.mozilla.com/D40751
MANUAL PUSH: avoid closing autoland while all docker images and
toolchains are rebuilt.
--HG--
rename : browser/config/tooltool-manifests/win32/build-clang-cl.manifest => browser/config/tooltool-manifests/win64/vs2017.manifest
Now that all GCC and related source tarballs extract to paths
independent of their version number, the scripts are all very
look-alike, so they can be consolidated.
Differential Revision: https://phabricator.services.mozilla.com/D40749
Bug 1479533 was proposing to add a similar functionality, but this
iteration avoids actually unpacking anything, and ensures
reproducibility by relying on the reproducible bits from the original
archives: file ordering, flags, etc. (since they are checksummed, those
are never going to change for a given archive).
Another notable difference is that this applies the repack on the fetch
task itself, rather than create a separate task to apply the repack. The
latter has advantages, in that it allows to change the repacking without
redownloading the original file from a third-party server, but in
practice, most changes to the repacking would trigger the download tasks
anyways.
This patch only takes care of changing the archive type (zip->tar), and
the compression type (anything->zstandard).
Differential Revision: https://phabricator.services.mozilla.com/D40740
This also allows toolchain tasks to use aliases via fetches, which they
currently aren't allowed via use_toolchain. There are more toolchains
now than there were when the restriction was added, and it might be
useful to be able to use aliases. The flip side is that there are some
risks involved with aliases, which is why the restriction was there in
the first place. Let's see how things play out.
Differential Revision: https://phabricator.services.mozilla.com/D40713
What this means is that the sources for clang/llvm are downloaded
separately from the toolchain build (which also means we finally only
download a given version of clang once for all platforms).
In turn, this means the build-clang.py script needs to start with an
existing llvm-project tree, and we choose to make build-clang.py expect
that it's run from the llvm-project root directory.
This also means we don't need to download git for the windows toolchain
task.
Differential Revision: https://phabricator.services.mozilla.com/D40402
The new StaticLocalAutoPtr smart pointer has a trivial destructor, so we will
either properly clean up this data or leak it on process shutdown. Either way,
we will not destroy it in a way that the underlying type does not support.
Differential Revision: https://phabricator.services.mozilla.com/D40842
--HG--
extra : moz-landing-system : lando
This was added in Firefox 38 and isn't used anywhere
in the codebase. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D40544
--HG--
extra : moz-landing-system : lando
This patch introduces a new Rust crate called `static_prefs`.
It also changes generate_static_pref_list.py to generate two new files.
- StaticPrefsCGetters.cpp: contains C getters, which are just wrappers around
the C++ getters. This is included into Preferences.cpp.
- static_prefs.rs: contains declarations for the C getters, plus the `pref!`
macro which provides nice syntax for calling the C getters. This is included
into static_prefs/src/lib.rs.
The new code is only generated for prefs marked with the new `rust` field in
the YAML. It's opt-in because there's no point generating additional code for
900+ static prefs when only about 20 are currently used from Rust.
This patch only marks a single pref (`browser.display.document_color_use`) with
`rust: true`. That pref isn't accessed from Rust code in this patch, but it's
necessary because the generated Rust code is invalid if there are zero
Rust-accessed prefs. (The next patch will access that pref and others from Rust
code.
Differential Revision: https://phabricator.services.mozilla.com/D40791
--HG--
extra : moz-landing-system : lando
generate_static_pref_list currently has two functions:
- generate_header(): this checks the YAML and generates most of the code.
- emit_header(): this does a bit of additional code generation and writes the
code to file.
This patch gives it a cleaner structure:
- check_pref_list(): this checks the YAML.
- generate_code(): this generates all the code. (It calls check_pref_list()
first.)
- emit_code(): this just writes the code to file.
The patch also improves the testing in test_generate_static_pref_list.py,
so that it checks the full contents of all generated files.
All these improvements will help with the next patch, which adds two additional
generated files.
The patch also fixes a couple of minor errors in the comment at the top of
StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D40790
--HG--
extra : moz-landing-system : lando
Remove unnecessary key values, replace componentWillReceiveProps, did some cleanup
Differential Revision: https://phabricator.services.mozilla.com/D39706
--HG--
extra : moz-landing-system : lando
It makes little sense to copy a writer (also an output iterator).
We're keeping it move-constructible (so it can be passed around for construction
purposes), but not move-assignable to help make more members `const`.
Differential Revision: https://phabricator.services.mozilla.com/D40622
--HG--
extra : moz-landing-system : lando
This makes it easier to grab all BlocksRingBuffer state variables:
- Range start and end.
- Number of pushed blocks/entries, number of cleared blocks/entries.
The function is thread-safe, and the returned values are consistent with each
other, but they may become stale straight after the function returns (and the
lock is released).
They are still valuable to statistics, and to know how far the range has at
least reached (but may go further soon).
Differential Revision: https://phabricator.services.mozilla.com/D40621
--HG--
extra : moz-landing-system : lando
Renamed `BPAutoLock` to `BaseProfilerAutoLock`.
DEBUG-build `~BaseProfilerMutex()` checks that it is unlocked.
Prevent `BaseProfilerMutex` and `BaseProfilerAutoLock` copies&moves.
DEBUG-build check that `Lock()` sees `mOwningThreadId`==0 (because that is the
initial value, and the value after a previous `Unlock()`).
Don't preserve atomic `mOwningThreadId` in JS recording.
Differential Revision: https://phabricator.services.mozilla.com/D40620
--HG--
extra : moz-landing-system : lando
`ProfilerMarkerPayload::Set...()` functions are only used by derived classes in
the same files, and these values could just be set during construction.
Differential Revision: https://phabricator.services.mozilla.com/D40619
--HG--
extra : moz-landing-system : lando
This fixes an edge case where it was possible for an HTMLMediaElement in the
middle of setup to have ownership transferred to a inactive document and deref a
null pointer. This happened because we have special handling for EME related
media where we perform more aggressive shutdown on for media in inactive
documents.
As far as I can tell, there's nothing specced that forbids performing EME
related functionality on elements in inactive documents. However, our code
already prevents doing so in other cases. E.g. if you create an inactive
document, place an HTMLMediaElement in it and try to setup EME related data on
it, then that will fail. So this fix just covers another such case.
While it would be nice to support doing these operations on inactive document's
media, it seems like very much an edge case, and something that would require a
large amount of reworking in how we handle inactive documents. We can cross that
bridge later should we ever need do so.
Differential Revision: https://phabricator.services.mozilla.com/D40482
--HG--
extra : moz-landing-system : lando
