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
When an MTest instruction results in a triangle structure, we now create an
empty block (like we did before bug 1595476) to get a diamond structure.
We did this for short-circuit operators but not for other cases.
We now also call improveTypesForTest for this block.
Differential Revision: https://phabricator.services.mozilla.com/D54535
--HG--
extra : moz-landing-system : lando
createFallthroughJoinBlock was necessary at some point, but it no longer is
because we know before the loop whether we have incoming edges.
Differential Revision: https://phabricator.services.mozilla.com/D54534
--HG--
extra : moz-landing-system : lando
* Use NonAssertingLabel in BaselineInterpreterHandler, similar to BaselineCodeGen fields.
* Make addDebugInstrumentationOffset report OOM.
No test case because the fuzz test is huge and this patch is based on the stack traces.
Differential Revision: https://phabricator.services.mozilla.com/D53630
--HG--
extra : moz-landing-system : lando
The patch changes InputStreamShim::AsyncWait() so it checks the buffer state and if there is some data available the callback is immediately notified. Without this check the callback would be notified only when new data is delivered from the network.
Differential Revision: https://phabricator.services.mozilla.com/D53972
--HG--
extra : moz-landing-system : lando
This should specifically prevent bug 1553938 from happening in the
future. Unfortunately it won't prevent other similar bugs from
happening.
Differential Revision: https://phabricator.services.mozilla.com/D52463
--HG--
extra : moz-landing-system : lando
It turns out that we don't actually want to install js-confdefs.h
because it contains macro definitions that can conflict when embedders
include JSAPI headers in their Autotools projects.
Differential Revision: https://phabricator.services.mozilla.com/D52462
--HG--
extra : moz-landing-system : lando
Whether ENABLE_INTL_API and ENABLE_TYPED_OBJECTS are defined, affects
the behaviour of JS_FOR_PROTOTYPES for the prototypes of Intl and
TypedObject. Therefore, these macros have to be available to embedders.
Rename them to JS_HAS_INTL_API and JS_HAS_TYPED_OBJECTS (in line with
the existing JS_HAS_CTYPES) everywhere they are used, and add them to
js-config.h.in.
Differential Revision: https://phabricator.services.mozilla.com/D52461
--HG--
extra : moz-landing-system : lando
Previously, if SpiderMonkey embedders linked to a copy of libmozjs built
with --enable-cranelift, --enable-wasm-gc, or --enable-fuzzing, then the
size of the ContextOptions data structure declared in the header file
would be different than the size of ContextOptions in the library,
likely leading to crashes. This makes all members of ContextOptions
independent of preprocessor macros. Any options not compiled into
SpiderMonkey will still be no-ops.
Differential Revision: https://phabricator.services.mozilla.com/D52460
--HG--
extra : moz-landing-system : lando
These are configure macros that start with JS_ and have an effect on the
public API declared in JSAPI header files, so they should be included in
the installed js-config.h header file.
Differential Revision: https://phabricator.services.mozilla.com/D52459
--HG--
extra : moz-landing-system : lando
If only relying on JS_64BIT to determine whether the system is 64-bits,
then the result will be incorrect when the header is installed as a
public header for use by embedders, and since JS_BITS_PER_WORD affects
the layout of structs in header files, things will go badly wrong.
This uses two other ways of determining pointer width, hopefully
cross-platform enough. __SIZEOF_POINTER__ is a GCC-ism and probably
works in Clang as well. UINTPTR_MAX is hopefully sufficiently
cross-platform as a last resort.
Differential Revision: https://phabricator.services.mozilla.com/D52458
--HG--
extra : moz-landing-system : lando
We should have the same public API available whenever possible, and make
it a no-op or make it throw immediately if JS was built without support
for it, instead of showing or hiding the API in header files using
configure macros. Otherwise embedders can easily get mismatches between
a library with functionality and header files without it, or vice versa.
There was no good reason why JS_GetErrorType() was nightly-only API, so
this also enables it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D52124
--HG--
extra : moz-landing-system : lando
This should have been obvious; we didn't end up declaring ElementType on WeakHeapPtr.
Differential Revision: https://phabricator.services.mozilla.com/D54552
--HG--
extra : moz-landing-system : lando
More use is being made of C++ move semantics recently and this imporves support for moving our GC wrapper types. In this case we don't want to trigger the pre-barrier on the source of the move because we are not modifying the object graph. We also do not want to check that wrapper contents are non gray, because this is valid (it's not valid to *create* a new heap pointer to a GC thing).
The patch adds a release() method to wrappers that returns the original contents of the wrapper after clearing it, without triggering a pre-barrier. Also it adds setUnchecked() methods to set wrapper contents without the gray marking check.
Differential Revision: https://phabricator.services.mozilla.com/D54305
--HG--
extra : moz-landing-system : lando
The crash occurs when dispatching a user input event which is a default action
of a raw user input event like `click` event caused by `mouseup` event if
the raw event's `isTrusted` is set to `false` accidentally during dispatch.
User input events are fired in the main process first. Then,
`EventStateManager` sends it to remote process from `PostHandleEvent()` if
necessary. However, at this time, `WidgetEvent::mFlags::mDispatchedAtLeastOnce`
is never rest, but its only referrer, `EventDispatcher::DispatchDOMEvent()`
assumes that when it's `true`, `WidgetEvent::mFlags:mIsBeingDispatched` is
`false`. Therefore, only in content process, `mouseup` event's `isTrusted` is
set to `false` by `EventTarget.dispatchEvent()` even while it's being dispatch.
And also the trusted state will be used for creating next event which is part
of the default action.
https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/dom/events/EventDispatcher.cpp#1121,1126,1130-1131,1135,1138,1143
Therefore, this patch makes `WidgetEvent::mFlags` reset `mDispatchedAtLeastOnce`
when it's copied across process boundary and make
`EventDispatcher::DispatchDOMEvent()` won't modify being dispatched events for
avoiding any odd issues.
Unfortunately, this patch adds "expected: FAIL" to the new WPT test only on
Windows. The failure reason is still unclear. I cannot reproduce the failure
on my Windows environment, but on Try Server, it fails permanently since
the driver succeeds to send the mouse click, but the button never receives
`mouseup` nor `click` event.
Differential Revision: https://phabricator.services.mozilla.com/D52988
--HG--
extra : moz-landing-system : lando
Sylvestre Ledru
Gabriele Svelto
Krish De Souza
ssengupta
Mike de Boer
Tim Nguyen
Jon Coppeard
Nicolas Chevobbe
Andreas Tolfsen
Ted Campbell
Martin Stransky
Jan de Mooij
Michael Ratcliffe
Michal Novotny
Mu Tao
Philip Chimento
Raymond Liu
Jan Varga
Mihai Alexandru Michis
Csoregi Natalia
Emilio Cobos Álvarez
Masayuki Nakano
Gurzau Raul