feat(serve): Add server-side handlers for Test262 tests [pt 2/5] #56841
+296
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpt-pr-bot
requested review from
DanielRyanSmith,
foolip,
jgraham and
jonathan-j-lee
jcscottiii
pushed a commit
that referenced
this pull request
Dec 18, 2025
…e tests This commit completes the core integration of Test262 into the WPT runner (`wptrunner`), enabling the execution of Test262 JavaScript conformance tests within the browser environment. This work builds upon the manifest tooling (PR 1 #56840) and server-side handling (PR 2 #56841) to provide a full end-to-end testing solution for Test262. Key components introduced and integrated: - **Client-Side Harness:** New JavaScript files (`harness-adapter.js`, `testharness-client.js`, `testharness.js`) under `resources/test262/` provide the necessary environment for Test262 tests to execute in an `iframe` and report results back to the main WPT testharness. - **Test262 Assertion Libraries (Vendored):** For the purpose of enabling these initial smoke tests, the standard Test262 assertion libraries (`assert.js` and `sta.js`) are directly placed into `third_party/test262/harness/`. This provides the immediate dependencies required by the smoke tests. An autoamted vendoring solution, including version tracking via `vendored.toml`, will be implemented in a subsequent PR focused on automated updates, as described in the RFC. - **Wptrunner Integration:** Modifications to `tools/wptrunner/wpttest.py` and `tools/wptrunner/browsers/*.py` enable `wptrunner` to recognize the `test262` test type and execute it using existing testharness executors. - **Smoke Tests and Metadata:** A suite of basic Test262 smoke tests (`infrastructure/test262/`) and their corresponding expected results (`infrastructure/metadata/infrastructure/test262/`) are added to verify the correct functioning of the entire integration. - **Linting Exemption:** `lint.ignore` is updated to exclude the vendored Test262 harness files from linting, respecting their upstream style. This integration allows browser vendors to run Test262 directly with `wptrunner`, streamlining conformance testing efforts as specified in the RFC: web-platform-tests/rfcs#229 This commit is the third in a series of smaller PRs split from the larger, original implementation in #55997.
jcscottiii
changed the title
jcscottiii
changed the title
jcscottiii
pushed a commit
that referenced
this pull request
Dec 18, 2025
…e tests This commit completes the core integration of Test262 into the WPT runner (`wptrunner`), enabling the execution of Test262 JavaScript conformance tests within the browser environment. This work builds upon the manifest tooling (PR 1 #56840) and server-side handling (PR 2 #56841) to provide a full end-to-end testing solution for Test262. Key components introduced and integrated: - **Client-Side Harness:** New JavaScript files (`harness-adapter.js`, `testharness-client.js`, `testharness.js`) under `resources/test262/` provide the necessary environment for Test262 tests to execute in an `iframe` and report results back to the main WPT testharness. - **Test262 Assertion Libraries (Vendored):** For the purpose of enabling these initial smoke tests, the standard Test262 assertion libraries (`assert.js` and `sta.js`) are directly placed into `third_party/test262/harness/`. This provides the immediate dependencies required by the smoke tests. An autoamted vendoring solution, including version tracking via `vendored.toml`, will be implemented in a subsequent PR focused on automated updates, as described in the RFC. - **Wptrunner Integration:** Modifications to `tools/wptrunner/wpttest.py` and `tools/wptrunner/browsers/*.py` enable `wptrunner` to recognize the `test262` test type and execute it using existing testharness executors. - **Smoke Tests and Metadata:** A suite of basic Test262 smoke tests (`infrastructure/test262/`) and their corresponding expected results (`infrastructure/metadata/infrastructure/test262/`) are added to verify the correct functioning of the entire integration. - **Linting Exemption:** `lint.ignore` is updated to exclude the vendored Test262 harness files from linting, respecting their upstream style. This integration allows browser vendors to run Test262 directly with `wptrunner`, streamlining conformance testing efforts as specified in the RFC: web-platform-tests/rfcs#229 This commit is the third in a series of smaller PRs split from the larger, original implementation in #55997.
jcscottiii
pushed a commit
that referenced
this pull request
Dec 18, 2025
…e tests This commit completes the core integration of Test262 into the WPT runner (`wptrunner`), enabling the execution of Test262 JavaScript conformance tests within the browser environment. This work builds upon the manifest tooling (PR 1 #56840) and server-side handling (PR 2 #56841) to provide a full end-to-end testing solution for Test262. Key components introduced and integrated: - **Client-Side Harness:** New JavaScript files (`harness-adapter.js`, `testharness-client.js`, `testharness.js`) under `resources/test262/` provide the necessary environment for Test262 tests to execute in an `iframe` and report results back to the main WPT testharness. - **Test262 Assertion Libraries (Vendored):** For the purpose of enabling these initial smoke tests, the standard Test262 assertion libraries (`assert.js` and `sta.js`) are directly placed into `third_party/test262/harness/`. This provides the immediate dependencies required by the smoke tests. An autoamted vendoring solution, including version tracking via `vendored.toml`, will be implemented in a subsequent PR focused on automated updates, as described in the RFC. - **Wptrunner Integration:** Modifications to `tools/wptrunner/wpttest.py` and `tools/wptrunner/browsers/*.py` enable `wptrunner` to recognize the `test262` test type and execute it using existing testharness executors. - **Smoke Tests and Metadata:** A suite of basic Test262 smoke tests (`infrastructure/test262/`) and their corresponding expected results (`infrastructure/metadata/infrastructure/test262/`) are added to verify the correct functioning of the entire integration. - **Linting Exemption:** `lint.ignore` is updated to exclude the vendored Test262 harness files from linting, respecting their upstream style. This integration allows browser vendors to run Test262 directly with `wptrunner`, streamlining conformance testing efforts as specified in the RFC: web-platform-tests/rfcs#229 This commit is the third in a series of smaller PRs split from the larger, original implementation in #55997.
jcscottiii
force-pushed
the
feat/test262-manifest-tooling
branch
from
ad5fa6b to
72ff9c7
Compare
This commit introduces the necessary server-side handlers within `wptserve`
to dynamically generate HTML wrappers for Test262 JavaScript tests.
This is needed to enable Test262 execution within WPT.
Key changes and their purpose:
- Introduction of several new `HtmlWrapperHandler` and `WrapperHandler`
subclasses (e.g., `Test262WindowHandler`, `Test262WindowTestHandler`,
`Test262StrictHandler`). These handlers are responsible for:
- Identifying Test262 test requests based on URL patterns.
- Dynamically constructing an HTML page that loads the Test262
`.js` test file within an isolated `iframe`.
- Injecting the required Test262 harness files (`assert.js`, `sta.js`)
and the WPT-specific `testharness-client.js` and `harness-adapter.js`
into the generated HTML.
- Processing Test262-specific metadata (like `includes` and `negative`
expectations) extracted by the manifest tooling from PR 1.
- Updates to `RoutesBuilder` in `serve.py` to map incoming requests
for Test262 test URLs to the appropriate new handler.
- Unit tests in `test_serve.py` to validate the correct
behavior of these new handlers, including URL rewriting, metadata
processing, and the structure of the generated HTML wrappers.
This work directly supports the integration of Test262 into WPT as detailed
in the RFC: web-platform-tests/rfcs#229
This commit is the second in a series of smaller PRs split from the larger,
original implementation in #55997.
jcscottiii
force-pushed
the
feat/test262-serve-handler
branch
from
16aa645 to
d5eb82e
Compare
jcscottiii
added a commit
that referenced
this pull request
Dec 18, 2025
…e tests This commit completes the core integration of Test262 into the WPT runner (`wptrunner`), enabling the execution of Test262 JavaScript conformance tests within the browser environment. This work builds upon the manifest tooling (PR 1 #56840) and server-side handling (PR 2 #56841) to provide a full end-to-end testing solution for Test262. Key components introduced and integrated: - **Client-Side Harness:** New JavaScript files (`harness-adapter.js`, `testharness-client.js`, `testharness.js`) under `resources/test262/` provide the necessary environment for Test262 tests to execute in an `iframe` and report results back to the main WPT testharness. - **Test262 Assertion Libraries (Vendored):** For the purpose of enabling these initial smoke tests, the standard Test262 assertion libraries (`assert.js` and `sta.js`) are directly placed into `third_party/test262/harness/`. This provides the immediate dependencies required by the smoke tests. An autoamted vendoring solution, including version tracking via `vendored.toml`, will be implemented in a subsequent PR focused on automated updates, as described in the RFC. - **Wptrunner Integration:** Modifications to `tools/wptrunner/wpttest.py` and `tools/wptrunner/browsers/*.py` enable `wptrunner` to recognize the `test262` test type and execute it using existing testharness executors. - **Smoke Tests and Metadata:** A suite of basic Test262 smoke tests (`infrastructure/test262/`) and their corresponding expected results (`infrastructure/metadata/infrastructure/test262/`) are added to verify the correct functioning of the entire integration. - **Linting Exemption:** `lint.ignore` is updated to exclude the vendored Test262 harness files from linting, respecting their upstream style. This integration allows browser vendors to run Test262 directly with `wptrunner`, streamlining conformance testing efforts as specified in the RFC: web-platform-tests/rfcs#229 This commit is the third in a series of smaller PRs split from the larger, original implementation in #55997.
This was referenced Dec 18, 2025
DanielRyanSmith
approved these changes
Dec 18, 2025
Contributor
DanielRyanSmith
left a comment
DanielRyanSmith
left a comment
There was a problem hiding this comment.
This suggestion came from a Gemini code review:
File: tools/serve/serve.py
Code: with open(path, encoding='ISO-8859-1') as f:
Criticism: Using ISO-8859-1 to read Test262 source files is risky and possibly incorrect.
The Problem: Test262 contains tests with Unicode identifiers and string literals (stored as UTF-8). Reading them as ISO-8859-1 treats the bytes as Latin-1 characters. If the server framework later encodes the response as UTF-8 (which is standard), multi-byte characters will be "double-encoded" (mangled). For example, a UTF-8 byte sequence for a specific emoji will be read as separate Latin-1 characters and then encoded again.
Fix: Use encoding='utf-8'. If you are worried about mixed encodings in legacy tests, use errors='replace', but Test262 should be UTF-8 compliant.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit introduces the necessary server-side handlers within
wptserveto dynamically generate HTML wrappers for Test262 JavaScript tests. This is needed to enable Test262 execution within WPT.Key changes and their purpose:
HtmlWrapperHandlerandWrapperHandlersubclasses (e.g.,Test262WindowHandler,Test262WindowTestHandler,Test262StrictHandler). These handlers are responsible for:.jstest file within an isolatediframe.assert.js,sta.js) and the WPT-specifictestharness-client.jsandharness-adapter.jsinto the generated HTML.includesandnegativeexpectations) extracted by the manifest tooling from PR 1 (feat(manifest): Add initial tooling for Test262 test types [pt 1/5] #56840 .RoutesBuilderinserve.pyto map incoming requests for Test262 test URLs to the appropriate new handler.test_serve.pyto validate the correct behavior of these new handlers, including URL rewriting, metadata processing, and the structure of the generated HTML wrappers.This work directly supports the integration of Test262 into WPT as detailed in the RFC: web-platform-tests/rfcs#229
This commit is the second in a series of smaller PRs split from the larger, original implementation in #55997.