nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
nsIFrame::BuildDisplayListForStackingContext() will check the existence
of transform animations, so we need to update
nsLayoutUtils::HasAnimationsOfPoperty(). However, checking only
eCSSProperty_transform is not enough. We have to check all the transform-like
properties. Therefore, we update these functions to accept a property
set as the argument, and pass a collection of transform-like properties
into them.
Differential Revision: https://phabricator.services.mozilla.com/D20412
--HG--
extra : moz-landing-system : lando
In the next patch in this series, we will add another test to
web-animations/interfaces/Document/getAnimations.html. Doing so would cause an
existing async_test to fail since it will affect the result of
Document.getAnimations() because async_tests run in parallel. To avoid that,
this patch converts the async_test to a promise_test since promise_tests, unlike
async_tests, wait for the previous promise_tests to finish before running.
Differential Revision: https://phabricator.services.mozilla.com/D20240
--HG--
extra : moz-landing-system : lando
Builds that should have jemalloc enabled already have it enabled by
default. An explicit --enable-jemalloc is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D20273
It used to be that --enable-eme on its own had some effect, but that's
not the case anymore. The only thing it does as of bug 1300654 is to
switch the defaults in the Firefox configuration.
Reflect that in how we handle --enable-eme.
Differential Revision: https://phabricator.services.mozilla.com/D20270
In bug 1522354, we changed host and target detection to not invoke
config.sub, assuming the output from config.guess would satisfy our
needs in split_target.
It turns out that on some plaforms, that doesn't work out, so, while we
still skip config.sub, we now catch errors from split_target when doing
so, and try again after running config.sub when split_target fails.
Differential Revision: https://phabricator.services.mozilla.com/D19937
Since bug 1522788, mach invokes a part of configure as part of getting
mozconfig and target information for its own purpose. The problem is
that the sandboxed code may sys.exit(), which then makes mach silently
exit.
So when the sandboxed configure code does sys.exit(), instead of
silently failing, we catch the exit call, and print out what we
captured.
Differential Revision: https://phabricator.services.mozilla.com/D19936
Currently, artifact builds pull from some task they determine from the
job type, and finding a pushhead.
Sometimes that latter fails, most notably on automation. But automation
can already know the right task to use without guesswork.
This change allows artifact builds to pull from a specific taskid given
through an environment variable, and make tasks from the artifact-build
kind (not the --artifact builds from try) use that.
Remove the workaround from bug 1382982 because it's now dead code.
Differential Revision: https://phabricator.services.mozilla.com/D19881
The build script currently is doing some unnecessary steps:
- Running `gclient` only prints out an help message. It is a step
indicated in various documentations, but is only necessary to keep
depot-tools up-to-date, which they are, since we just cloned it.
- The `fetch v8` command creates a v8 directory, no need to create
another layer.
- `gclient sync` is run as part of `fetch`. Same as `gclient`, this step
is only given in documentations to keep things up-to-date on an existing
clone, but we just freshly got one.
- Same goes for `git pull && gclient sync`
- `git checkout master` is not necessary, as `fetch` gets us there
already (albeit, in a detached head state)
- install-build-deps.sh installs build dependencies for chrome or
whatever. That's way too much for v8, that barely needs pkg-config and
glib, which we now install in the docker image.
Differential Revision: https://phabricator.services.mozilla.com/D20082
It was supposed to be doing this already, but we were instead removing _all_ text
nodes, which led the the "Learn More" link not showing up in popupnotifications
Differential Revision: https://phabricator.services.mozilla.com/D20379
--HG--
extra : moz-landing-system : lando
Splitting part of OGLShaderProgram.h out into OGLShaderConfig.h makes it
easier to keep GLContext.h included in OGLShaderProgram.h for inlining
purposes.
Differential Revision: https://phabricator.services.mozilla.com/D20017
--HG--
extra : moz-landing-system : lando
Received exit profiles are now stored in the main process' ActivePS and managed
there, including discarding expired profiles (when they don't intersect with the
parent's profile anymore).
nsProfiler may grab exit profiles from the profiler when the add-on needs them.
On shutdown, the profiler now includes non-expired exit profiles.
Differential Revision: https://phabricator.services.mozilla.com/D20277
--HG--
extra : moz-landing-system : lando
Make it always forward to the document's docshell. We rely on it being setup by
the time our stuff runs, and we cannot have multiple pres contexts per document
in different docshells anymore.
This allows me to also move some state to the document (about whether it's
currently loaded in a chrome docshell (nsPresContext::mIsChrome) and whether
it's a chrome origin image (nsPresContext::mIsChromeOriginImage), which will
help for bug 1490401 / bug 1418159.
The pres context already relies on having the docshell available on `Init` and
we don't properly handle dynamic changes to it.
The reason I store some state like whether the doc URI is chrome:// and whether
we're in a chrome docshell is not (only) to avoid recomputing it over and over,
but also to allow me to read them from Stylo (main-thread blocked, but poke at
that from multiple non-main-threads).
Differential Revision: https://phabricator.services.mozilla.com/D20301
--HG--
extra : moz-landing-system : lando
On integrated GPUs, we are typically completely bound by memory
bandwidth and the number of pixels that get written / blended.
On real world pages, it's often the case that we end up with
clip tasks that are long in one dimension but not the other, due
to box-shadow edges, clip mask segments etc. When this occurs,
the logic that tries to get a small 'used_rect' to clear targets
to fails, since the union of those ends up being a very large
rect that covers (most of) the surface. This can cost a lot of
GPU time on some integrated chipsets.
Instead, it appears to be much faster to issue multiple clears,
one for each clip mask region, which is typically < 10% of the
surface we were clearing previously.
However, we can also restore an old optimization we used to have
which means we can skip clears altogether in the common case. The
first mask in a clip task will write to all the pixels in the mask,
so we can draw that with blending disabled (also a significant win
on integrated GPUs) and skip the clear in these cases. With this
functionality in place, the multiplicative blend mode is only
enabled for any clips other than the first in a mask (this is
quite a rare case - most clip tasks end up with a single mask).
On low end GPUs driving a 4k screen, I've measured GPU wins of up
to 5 ms/frame on some real world pages with this change.
Differential Revision: https://phabricator.services.mozilla.com/D19893
--HG--
extra : moz-landing-system : lando
