This tries to maintain stylistic continuity, while also trying to decouple from
newtab as much as possible. This is a first foray, and future patches will
further this decoupling.
This also modifies about:asrouter to show an error message if the ASRouter devtools
pref is not set to true.
Differential Revision: https://phabricator.services.mozilla.com/D194811
This tries to maintain stylistic continuity, while also trying to decouple from
newtab as much as possible. This is a first foray, and future patches will
further this decoupling.
This also modifies about:asrouter to show an error message if the ASRouter devtools
pref is not set to true.
Differential Revision: https://phabricator.services.mozilla.com/D194811
This also re-runs npm install on browser/components/aboutwelcome to make sure everything in
package-lock.json is up-to-date.
Depends on D193122
Differential Revision: https://phabricator.services.mozilla.com/D193228
This directory is generated during builds and contains generated .class files for the annotation processor. These should not be checked into the repository.
Differential Revision: https://phabricator.services.mozilla.com/D191148
Vendor in WebGPU CTS so that we can run it against our implementation of WebGPU. This patch includes:
1. Some linting configuration tweaks, to silence issues that weren't straightforward to fix in CTS upstream.
2. Some WPT runner configuration to enable preferences, and skip MacOS testing altogether (since it's not targeted by our current work).
3. A new Rust binary crate that, when run from a development environment:
1. Creates a vendored copy of WebGPU CTS in `<gecko>/dom/webgpu/tests/cts/checkout/`.
2. Generates private Web Platform Tests (see also `<gecko>/testing/web-platform/docs/index.rst`). To do this, we:
1. Use upstream test generation via `npm` scripts, which creates a single `cts.https.html` file with thousands of variants.
2. Chunk the `cts.https.html` file into parts that Taskcluster can distribute without timing out individual jobs. IMO, this is the most likely part of these changes to need further iteration, because:
1. We currently naively divide tests by number of variant, and have made no effort to empirically prove that we're dividing execution time of chunks.
2. There is currently no stability in the distribution of tests per chunk. Test variants are essentially a flattened list of the tree structure used to organize tests. Adding a few tests that end up being placed in the middle of the list can cause the chunk with new tests _and all subsequent chunks_ to have their contents changed, which will probably cause a disproportionate number of line changes to review.:
3. Fix `script` tag(s) so they actually work with the WPT test runner for private tests (viz., in the `testing/web-platform/mozilla` directory).
The output of the new vendoring binary is designed make the above steps transparent. N.B. that no actual vendoring in of files has happened yet; the next patch will add the results of running this script.
Differential Revision: https://phabricator.services.mozilla.com/D169951
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
Vendor in WebGPU CTS so that we can run it against our implementation of WebGPU. This patch includes:
1. Some linting configuration tweaks, to silence issues that weren't straightforward to fix in CTS upstream.
2. Some WPT runner configuration to enable preferences, and skip MacOS testing altogether (since it's not targeted by our current work).
3. A new Rust binary crate that, when run from a development environment:
1. Creates a vendored copy of WebGPU CTS in `<gecko>/dom/webgpu/tests/cts/checkout/`.
2. Generates private Web Platform Tests (see also `<gecko>/testing/web-platform/docs/index.rst`). To do this, we:
1. Use upstream test generation via `npm` scripts, which creates a single `cts.https.html` file with thousands of variants.
2. Chunk the `cts.https.html` file into parts that Taskcluster can distribute without timing out individual jobs. IMO, this is the most likely part of these changes to need further iteration, because:
1. We currently naively divide tests by number of variant, and have made no effort to empirically prove that we're dividing execution time of chunks.
2. There is currently no stability in the distribution of tests per chunk. Test variants are essentially a flattened list of the tree structure used to organize tests. Adding a few tests that end up being placed in the middle of the list can cause the chunk with new tests _and all subsequent chunks_ to have their contents changed, which will probably cause a disproportionate number of line changes to review.:
3. Fix `script` tag(s) so they actually work with the WPT test runner for private tests (viz., in the `testing/web-platform/mozilla` directory).
The output of the new vendoring binary is designed make the above steps transparent. N.B. that no actual vendoring in of files has happened yet; the next patch will add the results of running this script.
Differential Revision: https://phabricator.services.mozilla.com/D169951
This is still far from perfect given the limitations of the Storybook web components package, but I figured this was worth putting up since it's still an improvement over the current state of our args tables (I think).
I'm mostly leaving the default generated `custom-elements-manifest.json` alone save for filtering some internal properties we don't want documented since they shouldn't really be accessed directly. If it seems too strange to just have the `aria-label` attr documented we could possibly remove `attributes` from the docs for now (this happens because it's the only attr where the name is different from the property name).
Open to feedback/thoughts on if this is useful or too wonky for now given the weirdness around how Storybook creates naming collisions.
Differential Revision: https://phabricator.services.mozilla.com/D162599
- automatically create state directory (.moz-fast-forward) under top level or repo if missing
- automatically create log and tmp subdirectories if missing
- only execute use_config_env.sh once in nested scripts
- move default location for config_env under state directory
Differential Revision: https://phabricator.services.mozilla.com/D166492
Added .sh extension to all scripts.
edit-dictionary.sh:
* Convert to utf-8 before editing, and back to iso-8859-1 before saving
* Place a copy of the utf-8 dictionary inside the utf8 folder, and store the iso-8859-1 in place
make-new-dict.sh:
* Use .txt extension for support wordlists, and place them in a subfolder
* Exclude words in mozilla-exclusions.txt from the generated dictionary
* Save 5-mozilla-*.txt files to utf-8
Depends on D165304
Differential Revision: https://phabricator.services.mozilla.com/D165305
This patch will rewrite all chrome:// URLs in .mjs files, but it isn't
emitting proper URLs for assets. This means that JS imports will map
correctly, but any img/css references won't have a valid path outside of
local development and CSS files that use @import will not resolve imports
correctly.
To reference images and CSS files you will still need to ensure those files
are in the Storybook static path and use a separate URL to reference them
in the `window.IS_STORYBOOK` case.
Differential Revision: https://phabricator.services.mozilla.com/D165060
This provides a basic Storybook set up for us to develop with
Storybook locally.
Quick start (MacOS, Linux, WSL):
./mach npm --prefix=browser/components/storybook ci
./mach npm --prefix=browser/components/storybook run storybook
Differential Revision: https://phabricator.services.mozilla.com/D144223
