There are 2 changes in this patch.
In js-property-provider, we iterate over a Set
and delete item we don't want into instead of
turning the Set into an array, filter on it, and
convert it back to a new Set.
In the autocomplete function, we don't use regexp
anymore in the sort callback as we already have
a way to tell if we're performing an element access.
Differential Revision: https://phabricator.services.mozilla.com/D19471
--HG--
extra : moz-landing-system : lando
When the underlying image request (imgIRequest) changes for an image, we
need to ensure that we invalidate the cached WebRenderImageData such that
the image container stored therein is updated to be for the correct
image. This gets a little tricky because some display items store both
the current and previous images, and choose to display the latter if the
former is not yet ready. We also don't know what image the image
container belongs to. As such, we now compare the producer ID of the
current frame in the image container, to the expected producer ID of the
current image request. If they don't match, we must regenerate the
display list.
Differential Revision: https://phabricator.services.mozilla.com/D19699
In order to get the alpha channel when encoding BMP images from a
surface, we need to supply bmp=32 in the encoder options.
Differential Revision: https://phabricator.services.mozilla.com/D19835
Translation of wasm into MIR is currently set up to handle multiple nested
function call instances simultaneously, using a stack of CallCompileState
records to keep track of the per-open-call state. This is an optimisation
intended to allow interleaved evaluation and pushing of stack-resident
outbound arguments. However, this was predicated on the assumption of
pre-order Wasm encoding, which is no longer valid -- encoding is post-order.
The compiler's operand (wasm) stack tracks MIR value nodes, which are by
definition already evaluated -- it doesn't track unevaluated expression trees.
Consequently, by the time we arrive at a wasm call instruction, we have to
hand the MIR nodes for all the arguments, so the possibility of evaluating
arguments whilst marshalling the arguments no longer exists.
This patch:
* removes FunctionCompiler::callStack_ and CallCompileStateVector
* removes CallCompileState::{maxChildStackBytes_, spIncrement_, stackArgs_ and
childClobbers_}, since they are no longer necessary.
* removes CallCompileState::lineOrBytecode_ and just passes it directly to
where it's needed. It's only remaining use inside CallCompileState was to
carry that value (eg) from EmitCall up to callDirect/callImport.
* removes CallCompileState::startCall as that becomes a no-op
* propagates the fact that CallCompileState::spIncrement_ is always zero,
through the MIR (MWasmCall et al) and into emitWasmCallBase(). Hence the
field disappears from MWasmCall.
--HG--
extra : rebase_source : ffbcb681c6c632079275f0cb0b8c49ddc247dc34
Similar to the previous patch, this adds two jobs. One that
cross-compiles the binaries produced by `cargo test` and publishes them
as an artifact. The other job downloads the artifact and runs the
resulting binaries.
Differential Revision: https://phabricator.services.mozilla.com/D19370
--HG--
extra : source : 79120d13e713114032263c0851455ec5f981d72c
One job (which runs on a Linux docker worker) cross compiles wrench in
two configurations (regular and headless) and publishes artifacts with
the binaries. The other job (which runs on macOS) downloads the
artifacts and uses them to run the WebRender macOS CI release-mode
scripts, which basically consists of running the WebRender reftest
suite.
Differential Revision: https://phabricator.services.mozilla.com/D19369
--HG--
extra : source : 028c0ed368b844a4e54f3c38177b0fe65211d484
For some reason running these via cross-compiled wrench in Mozilla
automation produces a few pixels difference.
Differential Revision: https://phabricator.services.mozilla.com/D19368
--HG--
extra : source : f06721b552a819e4d2456f1c31d62c782d9a42cb
This introduces some env vars to allow running cross-compiled
binaries instead of running things on the builder. Additionally
the `cargo test --features "ipc"` check is modified to be `check`
instead since there are no actual tests being run by that command.
The only thing we lose is a rustdoc example check but we are
checking that on Linux anyway so doing it for Mac is redundant.
Differential Revision: https://phabricator.services.mozilla.com/D19367
--HG--
extra : source : ee403c79877e028c58fa9091dd360fe50a80af37
The shebang at the top of fetch-content doesn't work on macOS because
the path to python3 is not /usr/bin. Using /usr/bin/env doesn't work
properly on all platforms either so instead we invoke the script using
the currently running python executable.
Differential Revision: https://phabricator.services.mozilla.com/D19744
--HG--
extra : source : f6413e576a2169855f766085704570c9fc851ee2
This code already exists for other (non-run-task jobs) on docker worker,
so this patch just reuses the existing code but adds a bit to the
run-task schema to allow the task to opt in.
Differential Revision: https://phabricator.services.mozilla.com/D19365
--HG--
extra : source : e9f887f489e59e828c7a62a4818c32cb5121f182
The main reason for this change is that we don't really want to share
compartments across same-origin navigations in the same tab (because that will
tend to keep the oldest global involved alive, due to CCWs and
XPCWrappedNatives allocated in that global). We could somehow flag
compartments as not sharable when we navigate, but it's simpler to just switch
zones, since we restrict our search of shareable compartments to a single zone.
A side benefit is that this way the lifetime of objects in a single zone is
more likely to be similar.
Differential Revision: https://phabricator.services.mozilla.com/D19797
--HG--
extra : moz-landing-system : lando
This wins at least 4 MB on AWSY's JS Opt number because we could have a lot of
unused arenas.
Differential Revision: https://phabricator.services.mozilla.com/D19707
--HG--
extra : moz-landing-system : lando
Similar to the previous patch, this adds two jobs. One that
cross-compiles the binaries produced by `cargo test` and publishes them
as an artifact. The other job downloads the artifact and runs the
resulting binaries.
Differential Revision: https://phabricator.services.mozilla.com/D19370
--HG--
extra : moz-landing-system : lando
One job (which runs on a Linux docker worker) cross compiles wrench in
two configurations (regular and headless) and publishes artifacts with
the binaries. The other job (which runs on macOS) downloads the
artifacts and uses them to run the WebRender macOS CI release-mode
scripts, which basically consists of running the WebRender reftest
suite.
Differential Revision: https://phabricator.services.mozilla.com/D19369
--HG--
extra : moz-landing-system : lando
For some reason running these via cross-compiled wrench in Mozilla
automation produces a few pixels difference.
Differential Revision: https://phabricator.services.mozilla.com/D19368
--HG--
extra : moz-landing-system : lando
This introduces some env vars to allow running cross-compiled
binaries instead of running things on the builder. Additionally
the `cargo test --features "ipc"` check is modified to be `check`
instead since there are no actual tests being run by that command.
The only thing we lose is a rustdoc example check but we are
checking that on Linux anyway so doing it for Mac is redundant.
Differential Revision: https://phabricator.services.mozilla.com/D19367
--HG--
extra : moz-landing-system : lando
The shebang at the top of fetch-content doesn't work on macOS because
the path to python3 is not /usr/bin. Using /usr/bin/env doesn't work
properly on all platforms either so instead we invoke the script using
the currently running python executable.
Differential Revision: https://phabricator.services.mozilla.com/D19744
--HG--
extra : moz-landing-system : lando
This code already exists for other (non-run-task jobs) on docker worker,
so this patch just reuses the existing code but adds a bit to the
run-task schema to allow the task to opt in.
Differential Revision: https://phabricator.services.mozilla.com/D19365
--HG--
extra : moz-landing-system : lando
clang-cl defines it on its own, although the value is slightly different
from __FUNCSIG__ (it doesn't contain the ABI, which doesn't really
matter). We've only been setting it this was on clang-cl by extension of
setting it for msvc.
Depends on D19616
Differential Revision: https://phabricator.services.mozilla.com/D19617
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Previously, this code looked parameters under `gecko.v2`, but that doesn't work
for projects using the out-of-tree taskgraph code, or Thunderbird. This moves
the parameter loading slightly later to vary the index used based on trust domain.
Differential Revision: https://phabricator.services.mozilla.com/D19028
--HG--
extra : moz-landing-system : lando
Profiler was previously fetching process name at the time of shutdown
serialization, at which point that name could have already been destroyed.
Now the child process just forwards the name as soon as it is given, so
the profiler can store it for later.
Differential Revision: https://phabricator.services.mozilla.com/D19732
--HG--
extra : moz-landing-system : lando
Modifying the manual font size settings while the GeckoFontScaleListener is
active is theoretically possible, but probably not the most sensible way of
using that API. Therefore, we prohibit it and throw an exception in that case.
There is one complication, though: The very same API is used by the font scale
listener itself in order to modify the font size settings according to the
system font scale. Therefore, we have to move the GeckoFontScaleListener into
the GeckoView package itself, so that we can provide a package-private internal
API that bypasses the above usage checks.
This means that going forward, Fennec needs to use the official GeckoView API
to communicate with the font scale listener, too. As we've moved out the Shared-
Preferences watching in part 5, this doesn't pose any insurmountable
difficulties.
Because for a short while I encountered some strange crashes where getRuntime()
in GeckoApplication apparently returned null while trying to initialise the
listener, I'm tying its initialisation to creation of the runtime, just to be on
the safe side.
Differential Revision: https://phabricator.services.mozilla.com/D18507
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoFontScaleListener.java
extra : moz-landing-system : lando
Some callers might prefer to manually set the font size in analogy to WebView's
WebSettings.setTextZoom(), respectively allow their users to do so.
Subsequently, we're also going to switch the GeckoFontScaleListener to operate
on those settings.
Because the effects of font inflation are more difficult to quantify than a
plain text zoom, we just check that operating the runtime setting sets the
corresponding Gecko pref. Besides, there already are further platform (ref)tests
checking the actual operation of font inflation itself.
Differential Revision: https://phabricator.services.mozilla.com/D17749
--HG--
extra : moz-landing-system : lando
With the dependencies on Fennec's GeckoPreferences and GeckoSharedPrefs gone, we
can now move the class into GeckoView in preparation for hooking it up to the
GeckoViewRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D18506
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java
extra : moz-landing-system : lando
For easier testing in Fennec, we want to continue watching the respective
SharedPreferences key and toggle the listener in response to *that* instead of
directly wiring it into our Settings menu (GeckoPreferences), however because
that functionality is Fennec-specific, we move that logic out of the font scale
listener itself.
In conjunction with this, we also decouple the enabled state of the listener
from its attached state.
The enabled state can now be toggled at all times, but unless the listener is
also attached to a context, it simply won't have any practical effect.
Differential Revision: https://phabricator.services.mozilla.com/D17746
--HG--
extra : moz-landing-system : lando
In practice, everything in the GeckoFontScaleListener will run on the UI thread,
so get rid of the `synchronized` methods and just enforce the threading
assumptions in the public API.
Differential Revision: https://phabricator.services.mozilla.com/D18505
--HG--
extra : moz-landing-system : lando
Going forward, we want to be able to toggle the enabled state at all times, and
being able to do this before calling initialize() seems a bit inconsistent.
Hence, we rename it to the more neutral-sounding attachToContext().
Differential Revision: https://phabricator.services.mozilla.com/D17745
--HG--
extra : moz-landing-system : lando
The GeckoFontScaleListener is intended to live as long as the app (and there-
fore Gecko) remains alive and consequently keeps a reference to the
*application* context, so the linter warning can be safely suppressed.
Also reorder imports to match coding style.
Differential Revision: https://phabricator.services.mozilla.com/D17743
--HG--
extra : moz-landing-system : lando
We support CTAP2 devices on one specific platform, making it hard for RPs to
decide whether or not Firefox will support the tokens they're asking for. This
adds a non-standard method to divine that information while Firefox moves toward
CTAP2 support.
Differential Revision: https://phabricator.services.mozilla.com/D19826
--HG--
extra : moz-landing-system : lando
Nicolas Chevobbe
Andrew Osmond
Razvan Maries
Julian Seward
Mike Hommey
Ed Lee
Daniel Varga
Kartikaya Gupta
Dorel Luca
Markus Stange
Coroiu Cristina
James Graham
Boris Zbarsky
Jan de Mooij
Daisuke Akatsuka
Paul Bone
Tom Prince
Thomas Daede
Gerald Squelart
Jan Henning
J.C. Jones