Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
We enable compilation of FOG/Glean on _all_ platforms.
We disable Glean initialization and metric recording on Android (GeckoView) by respecting MOZ_GLEAN_ANDROID.
This way GeckoView just works, consumers don't need to think about it (except in tests, these need to be disabled for Android builds).
Stubbing out the metric implementations will happen in the commits after
this one.
Differential Revision: https://phabricator.services.mozilla.com/D106766
Covers adding the new JS global `GleanPings` for JS, the new structs for C++ at
mozilla::glean_pings, ping-id and string-table-index codegen, the usual
boilerplate for JS and C++ stuff, and tests.
Unresolved:
* What happens if we call this on a non-parent process?
(This isn't a supported mode of operation)
Differential Revision: https://phabricator.services.mozilla.com/D98671
PathUtils is a path manipulation component to IOUtils, which is based on
simplified file I/O. This work is part of the larger goal of removing
osfile.jsm et al., ospath.jsm et al., and the entire OS.* namespace, especially
from the startup path.
No equivalent was provided for OS.Path.fromFileURI because it is unused.
Differential Revision: https://phabricator.services.mozilla.com/D95105
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This is only the basic outline.
It doesn't do anything yet, but compile.
As there are no metrics generated for it it can't look up anything.
To note: Actual metric types are implemented in XPIDL later.
The following (priviliged) JavaScript code will soon work (if the
corresponding metrics would be defined):
const { Glean } = ChromeUtils.import("resource://gre/modules/Glean.jsm");
Glean.shared.test_only.count_things.add(1);
Differential Revision: https://phabricator.services.mozilla.com/D92211
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This patch introduces a minimal, asynchronous Web IDL interface for
reading/writing whole files in privileged chrome code (main-thread and web
workers). All I/O is performed on a background thread. Pending I/O blocks
Firefox shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D78134
This patch introduces a minimal, asynchronous Web IDL interface for
reading/writing whole files in privileged chrome code (main-thread and web
workers). All I/O is performed on a background thread. Pending I/O blocks
Firefox shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D78134
This patch will
- create a chrome-only webdil interface `MediaController`
- expose supported keys via `MediaController` webidl interface
The advantage of doing so are
- to have a dedicated interface that is only used for MediaController that can be used for testing and our future plan (media hub)
More Details :
Currently, we access media controller's from `ChromeUtils` [1], but it causes a problem of creating a duplicated enum of the enum which we want to expose into Chrome JS.
Instead, we should create a media controller interface to access all its attibutes, which is more easier and clean.
In addition, we're planning to have a something like Chrome's media hub [2]. In order to do that, we have to expose some JS methods to allow us to control playback directly from Chrome JS.
[1] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/dom/chrome-webidl/ChromeUtils.webidl#485-493
[2] https://blog.google/products/chrome/manage-audio-and-video-in-chrome/
Differential Revision: https://phabricator.services.mozilla.com/D77757
In order to be able to reasonably debug error results from things like
JSWindowActor.sendQuery, we need to be able to clone errors across process
boundaries, so that they can be propagated to the caller that initiated a
query. The standard for the structured clone algorithm does not allow cloning
errors directly, so this patch instead adds a chrome-only wrapper object which
supports structured clone writing, and on reading, automatically decodes to
the error object it wraps. Callers who wish to clone an Error or Exception
object simply need to wrap it in a ClonedErrorHolder before sending.
Differential Revision: https://phabricator.services.mozilla.com/D50881
In order to be able to reasonably debug error results from things like
JSWindowActor.sendQuery, we need to be able to clone errors across process
boundaries, so that they can be propagated to the caller that initiated a
query. The standard for the structured clone algorithm does not allow cloning
errors directly, so this patch instead adds a chrome-only wrapper object which
supports structured clone writing, and on reading, automatically decodes to
the error object it wraps. Callers who wish to clone an Error or Exception
object simply need to wrap it in a ClonedErrorHolder before sending.
Differential Revision: https://phabricator.services.mozilla.com/D50881
