In order to render a table, we first check that console.table is
called with data that can be displayed in a table. Until now, we
were missing all the typed arrays.
This revealed some smaller issues:
- BigInt64Array were not marked as typed arrays on the server.
- Generating the repeatId for a message containing BigInts would
throw because BigInts can't be serialized.
We add test cases for all the typed array, and we take this opportunity
to add a test case to ensure object insides table cells can be expanded.
Differential Revision: https://phabricator.services.mozilla.com/D53155
--HG--
extra : moz-landing-system : lando
In a sadly similar bogosity as in bug 1595466, the multi-value stack
value shuffling code was confused about "stack height" (distance from
FP), "stack offset" (distance from SP), and whether the bytes to be
copied were towards the FP or the SP.
Differential Revision: https://phabricator.services.mozilla.com/D53660
--HG--
extra : moz-landing-system : lando
This bootstraps the remote agent from Rust so that we have access
to write to stderr using the eprintln!() macro. There is a future
intention to expand Rust usage in the remote agent by delegating
CDP and WebDriver Bi-Di protocol schema validation to serde.
The Rust port is faithful to the JS version in terms of functionality,
and in some places improves on the original design by enforcing
a strict division between flag handling code on one hand, and the
remote agent server on the other.
Differential Revision: https://phabricator.services.mozilla.com/D50289
--HG--
extra : moz-landing-system : lando
This change makes it possible to access the remote agent service
from C++ and Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50288
--HG--
extra : moz-landing-system : lando
Adds an XPIDL interface for the remote agent which we will later use to
initialise and start it from a new command-line handler written in Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50287
--HG--
extra : moz-landing-system : lando
Crafting nsIURIs in Rust is complicated. Allow RemoteAgent.listen()
to accept both strings and nsIURIs when called in JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D50286
--HG--
extra : moz-landing-system : lando
When calling RemoteAgent.listen() across XPIDL the function is run
asynchronously. In order to find out when the remote agent has started
listening we introduce a "remote-listening" system observer notification.
Differential Revision: https://phabricator.services.mozilla.com/D50285
--HG--
extra : moz-landing-system : lando
Although it currently makes no difference, we should ensure the
required preferences are set sooner, in case any of the internal
remote agent features depend on it.
Because we also cannot control when the nsICommandLineHandler for
the remote agent is invoked, setting it sooner rather than later,
seems a lot safer.
Differential Revision: https://phabricator.services.mozilla.com/D50283
--HG--
extra : moz-landing-system : lando
close() is meant to be failsafe in the sense that it should be
possible to call without side-effects.
We are currently setting up a lot of state in listen() that is not
cleaned up if the server eventually fails to start. Calling close()
when this happens will ensure any state listen() has accrued is reset.
Differential Revision: https://phabricator.services.mozilla.com/D50282
--HG--
extra : moz-landing-system : lando
Having init() as a separate function leads to inconsistencies about
how the required state is checked.
init() prevents the remote agent from being loaded when the
remote.enabled preference is false or it is attempted loaded into a
child process, but listen() already manipulates state before these
checks are run. This is probably not the intention, but an easy
mistake to make when the code flow is not crystal clear.
Since we never have a need to call init() independently, this patch
merges init() into listen().
Differential Revision: https://phabricator.services.mozilla.com/D50281
--HG--
extra : moz-landing-system : lando
All other XPCOM component manifests are named components.conf and
this makes the remote agent's conform with those.
It will also become apparent in a later patch in this changeset
that we need to register two XPCOM components: one implementing
the remote agent service, and one for handling command-line arguments.
Differential Revision: https://phabricator.services.mozilla.com/D50280
--HG--
rename : remote/RemoteAgent.conf => remote/components.conf
extra : moz-landing-system : lando
These were useful when implementing forwarding, and forgot to send them
earlier.
Differential Revision: https://phabricator.services.mozilla.com/D53767
--HG--
extra : moz-landing-system : lando
Generalizes the work on AnyRef to also allow FuncRef values to flow
out to JS through parameters on exits to JS or return values on
entries from JS. (But not from JS to wasm, because that requires more
elaborate type checking and is something we'll do later.)
Differential Revision: https://phabricator.services.mozilla.com/D50436
--HG--
extra : moz-landing-system : lando
Handle AnyRef argument passing and returns for the inlined JS->wasm
fast path.
Returns are easy: we unbox the AnyRef in the stub layer in the same
way as for other entries. Calls are trickier: we must box on the JS
side to fit into the current code structure, so there are some
type-sniffing fast paths to avoid unnecessary allocation and if those
fail then the generated code falls back to calling out to C++ to
create a box for general value boxing.
Differential Revision: https://phabricator.services.mozilla.com/D50031
--HG--
extra : moz-landing-system : lando
An AnyRef is an opaque pointer type to wasm but can hold any JS Value;
the Value is boxed when it enters wasm and unboxed when it enters JS.
This boxing and unboxing must also happen when wasm and JS interact
along the fast ("Jit") path, not just through the slow ("Interpreter")
path.
This patch allows an imported function (an exit) that returns anyref
to have a fast path; the Value that we receive from the import is
boxed into the wasm representation, which means allocating an object
for it if the wasm representation can't accomodate it directly
(currently only object or null).
It also allows an exported function (an entry) that accept an anyref
parameter to have a fast path; the value is similarly boxed in the
stub layer.
This patch does not handle argument passing for the inlined JS->wasm
path; that is handled by a separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D49728
--HG--
extra : moz-landing-system : lando
An AnyRef is an opaque pointer type to wasm but can hold any JS Value;
the Value is boxed when it enters wasm and unboxed when it enters JS.
This boxing and unboxing must also happen when wasm and JS interact
along the fast ("Jit") path, not just through the slow ("Interpreter")
path.
This patch (part 1) handles the AnyRef -> Value cases: when Wasm calls
JS with an AnyRef, or when Wasm returns to JS with an AnyRef, the
AnyRef is unboxed into a Value.
This patch does not handle the return value for the inlined JS->wasm
path; that will be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D49396
--HG--
extra : moz-landing-system : lando
The proper test for whether ref.func should return an original
imported function for a given function index is a double test: first
whether the index is in the import range, but then whether the
original imported function is itself an exported function.
This double test is visible several places in the code, notably in
Instance::initElems and in GetFunctionExport. The second part of the
test was however missing from Instance::funcRef.
Differential Revision: https://phabricator.services.mozilla.com/D53004
--HG--
extra : moz-landing-system : lando
Cleanup patch:
This documents the meaning of a 'funcref' value in wasm code (it is
always a pointer to a JSFunction for which IsWasmExportedFunction is
true) and implements a new abstraction, FuncRef, that can be used to
handle functions with more precision than AnyRef.
FuncRef and AnyRef are representationally compatible, so it is
possible to have common code paths using only AnyRef for convenience,
and to use FuncRef where we wish to be more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D53003
--HG--
extra : moz-landing-system : lando
Any button inside a form is by spec considered a submit button
(as mentioned here https://www.w3.org/TR/html401/interact/forms.html#h-17.5)
and so, when Enter was pressed while the form was focused, a click event
was being triggered on the first button found inside the form
(and the first button was the hidden close icon button).
Explicitly marking all the report panel buttons as type="button" prevent
the report panel from being wrongly cancelled in these scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D53633
--HG--
extra : moz-landing-system : lando
Generalizes the work on AnyRef to also allow FuncRef values to flow
out to JS through parameters on exits to JS or return values on
entries from JS. (But not from JS to wasm, because that requires more
elaborate type checking and is something we'll do later.)
Differential Revision: https://phabricator.services.mozilla.com/D50436
--HG--
extra : moz-landing-system : lando
Handle AnyRef argument passing and returns for the inlined JS->wasm
fast path.
Returns are easy: we unbox the AnyRef in the stub layer in the same
way as for other entries. Calls are trickier: we must box on the JS
side to fit into the current code structure, so there are some
type-sniffing fast paths to avoid unnecessary allocation and if those
fail then the generated code falls back to calling out to C++ to
create a box for general value boxing.
Differential Revision: https://phabricator.services.mozilla.com/D50031
--HG--
extra : moz-landing-system : lando
An AnyRef is an opaque pointer type to wasm but can hold any JS Value;
the Value is boxed when it enters wasm and unboxed when it enters JS.
This boxing and unboxing must also happen when wasm and JS interact
along the fast ("Jit") path, not just through the slow ("Interpreter")
path.
This patch allows an imported function (an exit) that returns anyref
to have a fast path; the Value that we receive from the import is
boxed into the wasm representation, which means allocating an object
for it if the wasm representation can't accomodate it directly
(currently only object or null).
It also allows an exported function (an entry) that accept an anyref
parameter to have a fast path; the value is similarly boxed in the
stub layer.
This patch does not handle argument passing for the inlined JS->wasm
path; that is handled by a separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D49728
--HG--
extra : moz-landing-system : lando
An AnyRef is an opaque pointer type to wasm but can hold any JS Value;
the Value is boxed when it enters wasm and unboxed when it enters JS.
This boxing and unboxing must also happen when wasm and JS interact
along the fast ("Jit") path, not just through the slow ("Interpreter")
path.
This patch (part 1) handles the AnyRef -> Value cases: when Wasm calls
JS with an AnyRef, or when Wasm returns to JS with an AnyRef, the
AnyRef is unboxed into a Value.
This patch does not handle the return value for the inlined JS->wasm
path; that will be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D49396
--HG--
extra : moz-landing-system : lando
The proper test for whether ref.func should return an original
imported function for a given function index is a double test: first
whether the index is in the import range, but then whether the
original imported function is itself an exported function.
This double test is visible several places in the code, notably in
Instance::initElems and in GetFunctionExport. The second part of the
test was however missing from Instance::funcRef.
Differential Revision: https://phabricator.services.mozilla.com/D53004
--HG--
extra : moz-landing-system : lando
Cleanup patch:
This documents the meaning of a 'funcref' value in wasm code (it is
always a pointer to a JSFunction for which IsWasmExportedFunction is
true) and implements a new abstraction, FuncRef, that can be used to
handle functions with more precision than AnyRef.
FuncRef and AnyRef are representationally compatible, so it is
possible to have common code paths using only AnyRef for convenience,
and to use FuncRef where we wish to be more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D53003
--HG--
extra : moz-landing-system : lando
Slightly reorganize file structure to make copying files over easier. Needs to land in conjunction with https://github.com/mozilla/geckoview/pull/94, which should land first.
Differential Revision: https://phabricator.services.mozilla.com/D48564
--HG--
rename : mobile/android/docs/geckoview/Gemfile => mobile/android/docs/Gemfile
rename : mobile/android/docs/geckoview/_config.yml => mobile/android/docs/_config.yml
extra : moz-landing-system : lando
The inner iframe sends a message M to the outer iframe when it
finishes loading, with the intention that the outer iframe will
send the message further to the top-level page. If, however, the
outer iframe's load handler didn't fire yet when it processes M,
it will throw an exception instead of forwarding M. This causes M
to get lost, and the test hangs.
Differential Revision: https://phabricator.services.mozilla.com/D53625
--HG--
extra : moz-landing-system : lando
Wrap around the pref `media.mediacapabilities.from-database` the option to enumerate MediaCapabilities database in `about:support` page. When the pref is off the button disappears and the enumeration method returns early.
Differential Revision: https://phabricator.services.mozilla.com/D53008
--HG--
extra : moz-landing-system : lando
Now since we use unicode_literals by bug 1210157, mercurial version check will be error due to `TypeError: environment can only contain strings`.
So we don't use unicode for os.environment['PATH'] when appending Java path.
Differential Revision: https://phabricator.services.mozilla.com/D53139
--HG--
extra : moz-landing-system : lando
promise_test() provides that a subtest is generated for each Task and run even
when an exception is thrown while running a previous Task.
This change also provides that Tasks that do not complete are reported
TIMEOUT, andTasks that are not reached due to TIMEOUT in a previous test
are reported NOTRUN.
The previous logic in Task.run() to generate a subtest for reporting a PASS
after calling _taskFunction() had a flaw that calls to done() during
_taskFunction() would synchronously call _testharnessDone() before the subtest
was generated.
Differential Revision: https://phabricator.services.mozilla.com/D51563
--HG--
extra : moz-landing-system : lando
Daniel Varga
Nicolas Chevobbe
Andy Wingo
Valentin Gosu
Sebastian Streich
danwalsh99
Andreas Tolfsen
Emilio Cobos Álvarez
Lars T Hansen
Dorel Luca
Luca Greco
Andrew Osmond
Logan Smyth
sotaro
Emily Toop
Yaron Tausky
Alex Chronopoulos
Francesco Lodolo (:flod)
Makoto Kato
Jan-Ivar Bruaroey
Jeff Walden
Karl Tomlinson
Bogdan Tara