Replaced `ScaffoldingConverter` with a set of `FfiValue*` classes. The
differences are:
* The new classes better match other `uniffi-bindgen-gecko-js` names,
and also use familiar UniFFI terms like `Lift` and `Lower`.
* Object handles are now freed if there's an error.
* The new classes store the FFI value internal rather than defining an
`IntermediateType` associated type.
* Moved header files into `mozilla/uniffi/` and removed the `UniFFI`
prefix from the filename. This avoids weird filenames like
`UniFFIFfiValue.h`
Differential Revision: https://phabricator.services.mozilla.com/D240696
Replaced `ScaffoldingConverter` with a set of `FfiValue*` classes. The
differences are:
* The new classes better match other `uniffi-bindgen-gecko-js` names,
and also use familiar UniFFI terms like `Lift` and `Lower`.
* Object handles are now freed if there's an error.
* The new classes store the FFI value internal rather than defining an
`IntermediateType` associated type.
* Moved header files into `mozilla/uniffi/` and removed the `UniFFI`
prefix from the filename. This avoids weird filenames like
`UniFFIFfiValue.h`
Differential Revision: https://phabricator.services.mozilla.com/D240696
The simplest possible way to produce the mapping,
which works correctly for 99% of imported modules,
and the remaining few dozen can be mapped manually
in config/fixed_paths.js.
Differential Revision: https://phabricator.services.mozilla.com/D241762
The "target/" rule matches all folders named target regardless of the depth.
Removing redundant entries and adding an exclusion for the devtools folder.
Differential Revision: https://phabricator.services.mozilla.com/D240728
We developed the new translations codebase using an "s" at the end, and
retained the old translations code under "translation". At this point
I'm unifying it so that it's all under "translations", which involves a
rename of the existing code. This way we will be consistent in our
naming practice.
Differential Revision: https://phabricator.services.mozilla.com/D239047
The only significant change here is the re-arrangement of where PdfJsOverridePrefs.js is ignored - moving the main ignore to Generated.txt (it was already excluded from prettier, but not other linters).
The .prettierignore additions are copy/paste updates from the other files to help keep the lists in sync.
Differential Revision: https://phabricator.services.mozilla.com/D236675
This doesn't move test_AboutNewTab.js, as this test exercises the AboutNewTab
module under browser/modules/ and the AboutNewTabService component under
browser/components/newtab.
Differential Revision: https://phabricator.services.mozilla.com/D233873
This doesn't move test_AboutNewTab.js, as this test exercises the AboutNewTab
module under browser/modules/ and the AboutNewTabService component under
browser/components/newtab.
Differential Revision: https://phabricator.services.mozilla.com/D233873
We're publishing updated schemas only to the mozilla-nimbus-schemas
package now, so we need to vendor them from there instead of
mozilla-nimbus-shared. Additionally, since the
github.com/mozilla/experimenter repo vendors the actual JSONSchema
files, we don't have to side-step the vendoring process with a custom
script and can use it how it was intended.
This updates us to mozilla-nimbus-schemas v2024.11.5.
Differential Revision: https://phabricator.services.mozilla.com/D227867
We're publishing updated schemas only to the mozilla-nimbus-schemas
package now, so we need to vendor them from there instead of
mozilla-nimbus-shared. Additionally, since the
github.com/mozilla/experimenter repo vendors the actual JSONSchema
files, we don't have to side-step the vendoring process with a custom
script and can use it how it was intended.
This updates us to mozilla-nimbus-schemas v2024.11.5.
Differential Revision: https://phabricator.services.mozilla.com/D227867
We're publishing updated schemas only to the mozilla-nimbus-schemas
package now, so we need to vendor them from there instead of
mozilla-nimbus-shared. Additionally, since the
github.com/mozilla/experimenter repo vendors the actual JSONSchema
files, we don't have to side-step the vendoring process with a custom
script and can use it how it was intended.
This updates us to mozilla-nimbus-schemas v2024.11.1.
Differential Revision: https://phabricator.services.mozilla.com/D227867
It looks like this was introduced in bug 427500, which an attempt to
upgrade the copy of MochiKit used in MochiTest. From what I can see,
that work was not completed.
We have almost identical tests in dom/tests/mochitest/ajax/mochikit/,
so I think we can just remove this directory.
Differential Revision: https://phabricator.services.mozilla.com/D225082
As per mozglue/static/README:
> mozglue/static contains parts of the mozglue library that can/should be
> statically linked to e.g. js/Gecko.
The compression part of MFBT is a good candidate for this.
Differential Revision: https://phabricator.services.mozilla.com/D221565
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
