cargo fix works by building under a specific config, so we can't hit both
sides of a mutually exclusive pair of cfgs, such as cfg(target_os) or
when cfg(feature) and cfg(not(feature)) both exist in the codebase.
Differential Revision: https://phabricator.services.mozilla.com/D29568
--HG--
extra : moz-landing-system : lando
Notably `extern crate foo as bar` is no longer supported
(must do it in Cargo.toml). Also stopped using euclid through webrender_api,
because it produces worse results in 2018.
Differential Revision: https://phabricator.services.mozilla.com/D29566
--HG--
extra : moz-landing-system : lando
0.1.21 mishandles cargo package renames, which are a required
feature for Rust 2018 support. The latest version fixes this.
Differential Revision: https://phabricator.services.mozilla.com/D29946
--HG--
extra : moz-landing-system : lando
The Content Security Policy tests were handling the smaller android preload
values that were #defined on Android by setting media.preload.default=2. Now
that we're detecting whether we're on cellular or not, and the android
emulators that our tests run on emulate a cellular connection, just setting
media.preload.default is no longer enough.
So set media.preload.default.cellular=2 in the CSP mochitests instead of
media.preload.default, to make the CSP mochitests pass in the Android
emulators.
Differential Revision: https://phabricator.services.mozilla.com/D29617
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
This allows Gecko to react to network link/status changes events as needed.
Differential Revision: https://phabricator.services.mozilla.com/D28942
--HG--
extra : moz-landing-system : lando
2019-05-06 22:41:10 +00:00
Eugen Sawin ext:(%2C%20Chris%20Pearce%20%3Ccpearce%40mozilla.com%3E)
In D25711, I added an arenaId member to `jemalloc_ptr_info_t` when `MOZ_DEBUG`
is defined. This modifies the GTest for `jemalloc_ptr_info()` to ensure that
the new member returns the correct value.
Differential Revision: https://phabricator.services.mozilla.com/D30087
--HG--
extra : moz-landing-system : lando
ColumnSetFrame always tries to reflow column content regardless of it's
dirtiness. Making ColumnSetWrapperFrame's children dirty can have the
same effect.
Differential Revision: https://phabricator.services.mozilla.com/D29435
--HG--
extra : moz-landing-system : lando
We use `columnCount == aConfig.mBalanceColCount - 1` in other places to
determine if we are at the last column. Advancing the column count at
the end of the loop make the condition consistent.
Differential Revision: https://phabricator.services.mozilla.com/D29433
--HG--
extra : moz-landing-system : lando
Under the hood, browsertime invokes a certain `visualmetrics.py`
script. That script depends on `ffmpeg` and ImageMagick's `convert`,
`compare`, and `mogrify` commands. It also depends on certain Python
packages.
So this installs those dependencies, and then wires up the evaluation
environment such that `./mach browsertime` can find the dependencies.
It also adds a `./mach visualmetrics` command for processing a
captured MP4 file in the same way that browsertime processes such a
file.
In order to avoid downloading dependencies multiple time, the existing
artifact cache is extracted. This is a small first step towards [Bug
1526021](https://bugzilla.mozilla.org/show_bug.cgi?id=1526021), which
might want to use this artifact cache as well.
At this time, hashes and filesizes are not verified. During
development, the upstream files changed multiple times, and it's not
worth being completely locked down while experimenting with this
functionality. If we start running this code in automation or in more
sensitive environments, we can build fetch tasks and TC indexes to
streamline the artifact gathering process.
It is expected that a future mach command will want to invoke
browsertime without suffering the overhead of invoking Python (and
mach, which is itself bulky) so a nod is given to exposing the
relevant environment pieces.
During testing, it was discovered that [MozillaBuild doesn't ship
git](https://bugzilla.mozilla.org/show_bug.cgi?id=1503028), so that
git repositories can't be used out-of-the-box on Windows. So instead
we use a [tarball link from github.com/$USER/$REPO/tarball/$COMMIT-LIKE](https://github.blog/2008-03-03-tarball-downloads/).
Differential Revision: https://phabricator.services.mozilla.com/D29442
--HG--
rename : python/mozbuild/mozbuild/test/test_artifacts.py => python/mozbuild/mozbuild/test/test_artifact_cache.py
extra : moz-landing-system : lando
[browsertime](https://github.com/sitespeedio/browsertime) is a harness
for running performance tests, similar to Mozilla's Raptor testing
framework. The Performance Team is using it locally with some
success, but we're running a heavily modified toolchain that is
challenging to install. This mach command is intended to be leverage
for getting more folks able to use browsertime easily.
In particular, the version of browsertime that this installs has
nalexander's changes to support testing GeckoView-based vehicles. If
this approach meets with approval, I'll continue to follow-up with
additional configuration and tooling layers to make it even easier to
drive GeckoView-based vehicles.
I elected to piggy-back install on the eslint installation process,
since this is very similar. To that end, I generalized what was there
very slightly. I elected not to try to move the existing code into a
more obvious shared location, although it might be possible, because
it wasn't clear what contexts the existing code would be invoked
from. In particular I wasn't certain the code could rely on a
complete mozbuild checkout.
I did need to ensure the local Node.js binary is early on the PATH;
this was an issue I ran into with my initial Node/Yarn prototyping
many months ago. At heart the issue is that package scripts in the
wild invoke a bare `node` or `npm` command; if there was a culture of
invoking $NODE or $NPM, this wouldn't be necessary. There's no harm
doing it for ESlint, and it will help the next person who wants to
install an NPM package for tooling in this manner.
Differential Revision: https://phabricator.services.mozilla.com/D26820
--HG--
extra : moz-landing-system : lando
Summary:
Our previous approach to making this intermediate available relied on being able
to add it to the user's NSS cert DB. This does work in the majority of cases,
but there are some situations where it doesn't work (e.g. if the user's DB is
set to read only, if they've configured Firefox to run in "nocertdb" mode, if
they have a master password but forgot it, and so on). This patch compiles the
intermediate in to Firefox in the same way we incorporate the root, so it should
always be available.
At the same time, this patch reverts the changes from
023dd959512e2cfa685187616560f91efa91183c and
1d35f8d88bdd007e01d42c4ff76c6d10d7c01a98 (the patches that implemented the
original approach) because they should no longer be necessary.
Reviewers: jcj!, kmag!
Tags: #secure-revision
Bug #: 1549249
Differential Revision: https://phabricator.services.mozilla.com/D30090
--HG--
extra : amend_source : dd475918be3f263a4a363c66a60edc708d3bdcca
extra : histedit_source : b6861a1d7c7ddbe07d5df73d76734d9a48ee3164%2C54cbc4b0446ff1ee3dc860bb2d3798ba8f662566
There's two ways we could get around this. We could add a path
around the prepared_for_frames assertion in GpuCache::end_frame,
or we can do this, and leave the TODO explicit with the
assertion. I took the latter approach because we can clear
the GpuCache / TextureCache through other routes than frame
building anyway, so we could hit this failure path before
any of the patches in this bug landed.
Differential Revision: https://phabricator.services.mozilla.com/D29884
--HG--
extra : moz-landing-system : lando
These aren't great names - I couldn't come up with better though.
We lose the symmetry of before/after but this clarifies a little
bit what they are doing.
Differential Revision: https://phabricator.services.mozilla.com/D29877
--HG--
extra : moz-landing-system : lando
If we run a GpuCache clear and do not update all documents, we run into
situations where the stale documents try to access things in the gpu
cache and just show random garbage. The solution is similar to what we
do for TextureCache, so I am just duplicating those signatures and providing
helpers in RenderBackend to access both together.
Differential Revision: https://phabricator.services.mozilla.com/D29860
--HG--
extra : moz-landing-system : lando
