Make the $PYTHON3 build var point to a full virtualenv bootstrapped with
the same libraries as the $PYTHON Python 2 build var. This allows us to
upgrade build tasks from $PYTHON to $PYTHON3.
This patch adds some debug logging and documentation to the Python
2 virtualenv so that it is easier to diagnose issues that may arise
from running two different Python interpreters in re-entrant
multiprocess routines.
Differential Revision: https://phabricator.services.mozilla.com/D50819
--HG--
extra : moz-landing-system : lando
Homebrew on OS X will change Python's sys.executable to a custom value
which messes with mach's virtualenv handling code. Override Homebrew's
changes with the correct sys.executable value.
Differential Revision: https://phabricator.services.mozilla.com/D54602
--HG--
extra : moz-landing-system : lando
Build a full sysroot by downloading the `wasi-sdk` repo, which has `llvm-project` and `wasi-libc` as submodules. `wasi-sdk` builds a `clang` in a unique configuration (with `wasm32-wasi` as a default target) and uses that `clang` to build the rest of the pieces for the wasm sysroot.
In principle it should be possible to build the sysroot using our in-house automation-built `clang`, but I kept running into strange, hard-to-diagnose issues when I attempted that. If someone else is able to straighten out all the compilation issues, we could replace this script and stop pulling in `wasi-sdk` entirely, which would result in a build that takes much less time overall. Until then, this will have to do to unblock the rest of the wasm sandboxing work.
Differential Revision: https://phabricator.services.mozilla.com/D54560
--HG--
extra : moz-landing-system : lando
An error means that javadoc is being copied to the incorrect folder as the {project} variable is incorrectly formatted
Differential Revision: https://phabricator.services.mozilla.com/D54731
--HG--
extra : moz-landing-system : lando
In GLES the default precision for ints is only 16 bits in the fragment shader.
Differential Revision: https://phabricator.services.mozilla.com/D54000
--HG--
extra : moz-landing-system : lando
The 'multi-brush' shader will have to dynamically switch between different brushes. In order to support that without needing the sum of all brush varying locations, allow aliasing a number of generic slots.
This patch makes the assumption that one a vec2 and a vec4 cost the same amount of varying register space, which is suggested by the glsl specification about shader locations. If it is not the case we can add more granularity to the varying slots which are all vec4 at the moment. This also assumes that an unused varying is always optimized out.
Differential Revision: https://phabricator.services.mozilla.com/D53726
--HG--
extra : moz-landing-system : lando
This is an experiment with only image and solid to see what the infrastructure can be like.
If it works out I'll extend the it with more brush types. More work will be needed to get text rendering in there as well.
The multi-brush shader includes all brushes that it potentially needs suport for. Which brushes actually get compiled in is then specified via WR_FEATURE defines.
Since brushes can't have the same names for their entry points, they specify the function to use via a macros (WR_BRUSH_VS_FUNCTION and WR_BRUSH_FS_FUNCTION).
Differential Revision: https://phabricator.services.mozilla.com/D53725
--HG--
extra : moz-landing-system : lando
This will allow the upcoming super-brush shader to select its behavior at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D53724
--HG--
extra : moz-landing-system : lando
This chanes the shader parsing code to only inject #included shader sources once (the first time) if they are included multiple times.
This will allow some extra flexibility needed by the multi-brush shader.
Differential Revision: https://phabricator.services.mozilla.com/D53651
--HG--
extra : moz-landing-system : lando
This adds a tp5n-multiproc output directory which contains postprocessed
versions of the tp5n set. They are processed to take iframes with relative
URLs and output absolute URLs with domains similar to their original
domains. This will help us better simulate a real-world case for Fission,
which will split processes based on the ETLD+1 of the domain.
Differential Revision: https://phabricator.services.mozilla.com/D53065
--HG--
extra : moz-landing-system : lando
This only affects console api calls where one of the
argument is an empty string. Since we don't quote
string arguments for those, it was difficult to spot
an empty string there.
Jest test are added, as well as a mochitest for the
console to make sure that we don't have unwanted
side effects (for evaluation results, object with
empty string properties, ...)
Differential Revision: https://phabricator.services.mozilla.com/D54687
--HG--
extra : moz-landing-system : lando
In this patch I have adapted the Docker file to make use of core18 and snapcraft3.
This is the recommended approach as stated here.
https://snapcraft.io/docks/t/creating-docker-images-for-snapcraft/11739
Specifically the part talking about replacing likes FROM ubuntu:xenial with FROM ubuntu:bionic.
In snapcraft.yaml.in, I adjusted the snap by using the gnome-3-28 extensions as described in
https://forum.snapcraft.io/t/the-gnome-3-28-extension/13485.
In addition, I followed the instructions presented by removing the unnecessary plugs relating
to the desktop extension and adding the relevant dbus slot.
As part of the build process, it required a bunch of extra staged packages which I have documented.
I also used the magic part from Ken Vandine's thunderbird snapcraft for updating mime info.
https://bazaar.launchpad.net/~ubuntu-desktop/thunderbird/snap/view/head:/snapcraft.yaml
I also removed the xdg-open as that seemed to not be enabling the building of the snap.
Differential Revision: https://phabricator.services.mozilla.com/D53355
--HG--
extra : moz-landing-system : lando
This makes use of display: contents; in order to preserve the row-based markup that is needed by JS to hide certain rows.
Differential Revision: https://phabricator.services.mozilla.com/D54243
--HG--
extra : moz-landing-system : lando
PerformanceEntry values are put in the `getterValue` property in
the descriptor, so whenever we want to display a table we need
to check if the value could be in there.
This highlighted an issue in the console layout when there is a
large number of cells, which we fix in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D54261
--HG--
extra : moz-landing-system : lando
Increasing the number of columnns highlighted some issues:
- Some element could be off-screen, the grid-template-columns
needed to be adjusted
- headers could be cut-off, we add a title on the element to
have the full content in a tooltip
- properties that are not defined were displayed as "undefined",
which is not really true, and take a lot of space. We render
them as an empty cell in such case now.
A test is added to check the max-column limit.
Differential Revision: https://phabricator.services.mozilla.com/D54260
--HG--
extra : moz-landing-system : lando
We want to display a visual hint to the user that the browser session
is under control by a browser-external client when the remote agent
is listening. The hint is the same as for when Marionette is active.
Differential Revision: https://phabricator.services.mozilla.com/D54270
--HG--
extra : moz-landing-system : lando
This changes the event Marionette emits when it is running from
"remote-active" to "remote-listening".
The background for this change is that the forthcoming Chromium-based
remote protocol uses the same observer notification to indicate
when it listens for browser-external connections. This means that
with this change, the visual hint presented to the user will also
be applied when the remote agent starts its HTTPD listener.
Unlike Marionette however, the remote debugging protocol may be used
for browser-internal applications and it is not appropriate to signal
that the browser is under remote control under those circumstances,
hence the naming change away from "active".
Differential Revision: https://phabricator.services.mozilla.com/D54269
--HG--
extra : moz-landing-system : lando
Split out the self-hosted handling from delazifyLazilyInterpretedFunction
since it will need to be handled differently when LazyScript merges with
JSScript.
Depends on D54526
Differential Revision: https://phabricator.services.mozilla.com/D54527
--HG--
extra : moz-landing-system : lando
Hide the check for LazyScript vs JSScript inside an accessor function.
Depends on D54525
Differential Revision: https://phabricator.services.mozilla.com/D54526
--HG--
extra : moz-landing-system : lando
The 'function()' method is already defined on BaseScript, so this is
straightforward to fix.
Differential Revision: https://phabricator.services.mozilla.com/D54525
--HG--
extra : moz-landing-system : lando
I think this has been effectively dead code for a few years because we no longer
create the triangle structure for JSOP_AND and JSOP_OR.
Depends on D54535
Differential Revision: https://phabricator.services.mozilla.com/D54536
--HG--
extra : moz-landing-system : lando
