Originally, RDD reused the GPU process selector since they were
using all the same services, and it reduced the number of places
that had to be touched. Now that RDD needs pref handling, it
needs its own process selector to avoid GPU inheriting pref
handling.
Differential Revision: https://phabricator.services.mozilla.com/D26566
--HG--
extra : moz-landing-system : lando
If there are a large number of untracked files in the working directory, hg
will attempt to print them all out with the default pager. This does not
interact very will with commands that are built atop this functionality. We
set HGPLAIN=1 so that the underlying hg will not attempt to use a pager.
Differential Revision: https://phabricator.services.mozilla.com/D26607
--HG--
extra : moz-landing-system : lando
The way that world content transform is calculated has some
inconsistencies related to transform flattening, compared to
the get_relative_transform implementation.
Reducing usage of this field will make it simpler to take
advantage of the external scroll offset, which is needed for
some of the planned picture caching improvements.
This patch removes the simple uses of world_content_transform,
but there are still a small number of more complicated uses that
need to be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D26651
--HG--
extra : moz-landing-system : lando
This records on Talos the number of allocated objects after creating, attaching and destroying a Tab Target.
Depends on D26107
Differential Revision: https://phabricator.services.mozilla.com/D26108
--HG--
extra : moz-landing-system : lando
Using official build flag was breaking tests on try as the builds
are done with the official build flag turned on.
Convert this module into a "supports" file, like other test-only files.
And also introduce a test for this module. It helps as we have to have
a browser.ini file in order to reference allocation-tracker.js,
and you can't have a browser.ini without any test in it.
Depends on D26105
Differential Revision: https://phabricator.services.mozilla.com/D26106
--HG--
extra : moz-landing-system : lando
The RemoteAgent.js script has (temporarily) changed name to
remote/command-line-handler.js, and the chrome component remote.jar
was not included during packaging. This patch fixes both these things.
Differential Revision: https://phabricator.services.mozilla.com/D26591
--HG--
extra : moz-landing-system : lando
This was fallout from Bug 1509572, which moved the "invalidation
smarts" to Gradle. Unfortunately, those smarts are not smart enough:
there are many situations where the annotations might change (a new
method) but where they don't actually change (a new method that isn't
annotated with @JNITarget).
Since we don't want to spend the time to make the "invalidation
smarts" truly smart, we need to bring back this little bit of Bug
1509572.
While we're here, we ensure that there is only one JNI wrapper
generation task for GeckoView and Fennec, regardless of variant.
Right now, those are named like:
- geckoview:generateJNIWrappersForGeneratedWithGeckoBinariesDebug
- app:generateJNIWrappersForFennecWithoutGeckoBinariesDebug
See https://bugzilla.mozilla.org/show_bug.cgi?id=1509539#c1 for some
discussion of these JNI wrapper generation tasks.
Differential Revision: https://phabricator.services.mozilla.com/D26427
--HG--
extra : moz-landing-system : lando
Check if the current parent element is an HTML template element and if it
is, append to the document fragment instead of it.
Differential Revision: https://phabricator.services.mozilla.com/D26768
--HG--
extra : moz-landing-system : lando
We add to `GARBAGE_DIRS` in the toplevel `Makefile.in` because all of
our Rust libraries share a single `CARGO_TARGET_DIR`, located in
topobjdir.
We add to `GARBAGE_DIRS` for Rust programs because Rust programs
currently do not share compilation artifacts with Rust libraries (as our
libraries are built with `panic=abort` and our programs are not, sharing
compilation artifacts between the two is a non-starter).
Differential Revision: https://phabricator.services.mozilla.com/D26762
--HG--
extra : moz-landing-system : lando
After replacing precise line information from .debug_line with coarse
line information from DW_AT_call_{file,line}, it's very likely that
adjacent line records actually refer to identical file and line
numbers. Such adjacent records are not really useful and take up more
space than they should in the symbol file. We might as well merge them
and save ourselves some space.
Differential Revision: https://phabricator.services.mozilla.com/D25473
--HG--
extra : moz-landing-system : lando
DW_TAG_subprogram DIEs sometimes have child DW_TAG_lexical_block DIEs
which in turn contain child DW_TAG_inlined_subroutine DIEs that we woud
like to look at. If we skip the DW_TAG_inlined_subroutine DIEs, we miss
important information. We therefore need to look through the
DW_TAG_lexical_block DIEs to find the DIEs that we are interested in.
Depends on D25471
Differential Revision: https://phabricator.services.mozilla.com/D25472
--HG--
extra : moz-landing-system : lando
We record the file and line that these subroutines were inlined from.
We'll use that information to provide more coarse-grained line
information in the next patch.
Depends on D25469
Differential Revision: https://phabricator.services.mozilla.com/D25470
--HG--
extra : moz-landing-system : lando
The DW_AT_call_file attributes that we eventually want to parse from
DW_TAG_inlined_subroutine DIEs refer to the file name table stored in
the .debug_line section. To resolve those DW_AT_call_file attributes,
we need access to that table after parsing of the appropriate
.debug_line bits is done. This patch adds support for extracting that
information from the .debug_line parsing process.
Differential Revision: https://phabricator.services.mozilla.com/D25469
--HG--
extra : moz-landing-system : lando
It's the caller's responsibility to have up-to-date styles, and
nsComputedDOMStyle (which is the only of those callers that could ever care
about EffectCompositor stuff) already does it.
There's no need to explicitly update animation rules from here, since it would
only have a difference for display: none subtrees anyway (otherwise we re-use
the cached style already in the element before having a chance to process the
potential animation restyles).
My guess is that this was just copy-pasta from other functions. This doesn't
break any test.
Differential Revision: https://phabricator.services.mozilla.com/D25458
--HG--
extra : moz-landing-system : lando
There are some that only have one caller, and some slightly confusing naming.
Hopefully make it a bit clearer.
Differential Revision: https://phabricator.services.mozilla.com/D25457
--HG--
extra : moz-landing-system : lando
This switches nsFrameSetFrame's hacky frame construction codepath to operate on
the flattened tree, since it made me a bit more comfortable about it (all layout
should operate on is the flattened tree, though in this cause this should not
cause any web-observable behavior change, since <frameset> can't be a shadow
host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles
lazily in descendants of display: none elements, and even though this code
doesn't check on display: none _on the children_, the parent element should
never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the <area> elements referencing an
image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for
LazyComputeBehavior::Allow on the document element in order to check the
viewport styles propagation, since the root element can't have display: none
ancestors. But we run that code before actually constructing the doc element
containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now,
since we need to keep using it for the <body>, since the document element could
be display: none itself, and we propagate the overflow styles in that case
still. I filed https://github.com/w3c/csswg-drafts/issues/3779 to potentially
change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
--HG--
extra : moz-landing-system : lando
Some of these were unused, some of them were only used in combination with
others, so I've unified them.
In particular, Forgetful and ClearAnimationOnlyDirtyDescendants were used only
together for a very specific task (the final animation traversal), so I merged
them into something that has that name.
ClearDirtyBits was unused, so I removed along with some code that would no
longer be called.
Differential Revision: https://phabricator.services.mozilla.com/D25454
--HG--
extra : moz-landing-system : lando
After bug 1530908 changed LTO to be environment driven, the macosx64
nightly mozconfig enables LTO by setting MOZ_LTO=1. The add-on-devel
mozconfig tried to disable LTO by using --disable-lto, but the
environment variable takes precedence, leaving LTO enabled for these
builds. This pushed the build time up to be close to the max runtime for
the task, causing frequent intermittent failures.
We should 'unset MOZ_LTO' everywhere that --disable-lto was used, and
'export MOZ_LTO=1' everywhere --enable-lto was used.
Differential Revision: https://phabricator.services.mozilla.com/D26608
--HG--
extra : moz-landing-system : lando
When the test font is activated, the notification of the font configuration change
may be handled asynchronously by content processes, so that it's possible the content
process has not yet handled the update at the point when registerFont() detects the
change and returns to the test script.
(This issue becomes more acute with the upcoming shared-font-list system, where the
OS notification is not handled by the content process at all; it's only handled by
the parent process, which then notifies content processes *after* it has updated the
font list. So there's an inherent latency between the update being recognized by the
chrome process - and therefore "ready" as far as the test script is concerned - and
content processes receiving and handling the change.)
To handle this, we can explicitly wait for the width of the rendered content to change,
which will indicate that the font configuration change has been handled by the content
process.
Differential Revision: https://phabricator.services.mozilla.com/D26570
--HG--
extra : moz-landing-system : lando
This only uses cross-platform tools, so switch to running these on linux, which
cuts the runtime down from ~20m to ~3m.
Differential Revision: https://phabricator.services.mozilla.com/D1080
--HG--
extra : moz-landing-system : lando
Michael Froman
Aaron Klotz
Mike Shal
Glenn Watson
Andrew Erickson
Alexandre Poirot
Andreas Tolfsen
Michael Kaply
Jason Laster
Nick Alexander
Brendan Dahl
Gijs Kruitbosch
Andrea Marchesini
Nathan Froyd
Ryan VanderMeulen
Dave Townsend
Bobby Holley
shindli
Sebastian Hengst
Oriol Brufau
Lina Cambridge
Emilio Cobos Álvarez
Andrew McCreight
Mathieu Leplatre
Jeff Walden
Brindusan Cristian
Chris Manchester
Cosmin Sabou
Jonathan Kew
Chris H-C
Tom Prince