feat(serve): Add server-side handlers for Test262 tests [pt 2/5] by jcscottiii · Pull Request #56841 · web-platform-tests/wpt

jcscottiii · 2025-12-18T02:48:48Z

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 (feat(manifest): Add initial tooling for Test262 test types [pt 1/5] #56840 .
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.

…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.

DanielRyanSmith

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.

jcscottiii · 2025-12-19T18:43:33Z

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.

Handled

…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.

tools/serve/serve.py

Addressed feedback

jcscottiii · 2026-01-27T16:00:41Z

@jgraham This should be good to go now

…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 · 2026-03-12T21:22:48Z

As stated in the other PR, I adjusted the names of the javascript files. If all is well, I can adjust the PR description with the updated names.

DanielRyanSmith

Some more optional suggestions:

1. Module Execution Order in Test262WindowModuleTestHandler

The wrapper for Test262WindowModuleTestHandler defines the following script:

<script type="module">
  test262Setup();
  import {} from "%(path)s";
  test262Done();
</script>

This will not execute in the intended order. In JavaScript ES modules, static import declarations are hoisted. This means that the imported test module (%(path)s) will be fetched and evaluated before test262Setup() is executed. Since test262Setup() initializes the testing harness context (like assert or reporting mechanisms), the test will run without the required setup.

Furthermore, if the imported Test262 module utilizes top-level await, test262Done() will not wait for the module's execution to complete because import inside the same script tag doesn't block the execution of the surrounding synchronous code in the way one might expect when mixing static imports and inline code.

Recommendation:
Separate the setup and teardown into their own script blocks, or use dynamic import() to guarantee execution order.

<script type="module">
  test262Setup();
</script>
<script type="module">
  import "%(path)s";
</script>
<script type="module">
  test262Done();
</script>

Note: Using dynamic import("%(path)s").then(test262Done) might be more robust if top-level await is involved.

Optimizations

1. File Read Efficiency in Test262StrictHandler._get_script

In Test262StrictHandler._get_script, the file is loaded into memory entirely:

    def _get_script(self, request):
        path = self._get_filesystem_path(request)
        try:
            with open(path, encoding='utf-8') as f:
                yield f.read()
        except OSError:
            raise HTTPException(404)

Test262 files can occasionally be large. Reading the entire file into memory at once with f.read() before yielding might cause unnecessary memory overhead, especially if the server processes many concurrent requests.

Recommendation:
Yield the file in chunks instead of a single string.

            with open(path, encoding='utf-8') as f:
                while True:
                    chunk = f.read(8192)
                    if not chunk:
                        break
                    yield chunk

jcscottiii · 2026-03-13T15:39:42Z

Some more optional suggestions:

1. Module Execution Order in Test262WindowModuleTestHandler

The wrapper for Test262WindowModuleTestHandler defines the following script:
<script type="module">
  test262Setup();
  import {} from "%(path)s";
  test262Done();
</script>
This will not execute in the intended order. In JavaScript ES modules, static import declarations are hoisted. This means that the imported test module (%(path)s) will be fetched and evaluated before test262Setup() is executed. Since test262Setup() initializes the testing harness context (like assert or reporting mechanisms), the test will run without the required setup.

Furthermore, if the imported Test262 module utilizes top-level await, test262Done() will not wait for the module's execution to complete because import inside the same script tag doesn't block the execution of the surrounding synchronous code in the way one might expect when mixing static imports and inline code.

Recommendation: Separate the setup and teardown into their own script blocks, or use dynamic import() to guarantee execution order.
<script type="module">
  test262Setup();
</script>
<script type="module">
  import "%(path)s";
</script>
<script type="module">
  test262Done();
</script>
Note: Using dynamic import("%(path)s").then(test262Done) might be more robust if top-level await is involved.

Optimizations

1. File Read Efficiency in Test262StrictHandler._get_script

In Test262StrictHandler._get_script, the file is loaded into memory entirely:
    def _get_script(self, request):
        path = self._get_filesystem_path(request)
        try:
            with open(path, encoding='utf-8') as f:
                yield f.read()
        except OSError:
            raise HTTPException(404)
Test262 files can occasionally be large. Reading the entire file into memory at once with f.read() before yielding might cause unnecessary memory overhead, especially if the server processes many concurrent requests.

Recommendation: Yield the file in chunks instead of a single string.
            with open(path, encoding='utf-8') as f:
                while True:
                    chunk = f.read(8192)
                    if not chunk:
                        break
                    yield chunk

Thanks for the suggestions @DanielRyanSmith! I have implemented the module execution order fix. However, I left the streaming part alone for now. We would need to change handle_request in WrapperHandler to stream the whole response. Not just the part that calls _get_script

jgraham · 2026-03-16T09:50:14Z

tools/serve/test_serve.py

+Test262WindowHandler.__test__ = False  # type: ignore[attr-defined]
+Test262WindowTestHandler.__test__ = False  # type: ignore[attr-defined]
+Test262WindowModuleHandler.__test__ = False  # type: ignore[attr-defined]
+Test262WindowModuleTestHandler.__test__ = False  # type: ignore[attr-defined]
+Test262StrictWindowHandler.__test__ = False  # type: ignore[attr-defined]
+Test262StrictWindowTestHandler.__test__ = False  # type: ignore[attr-defined]
+Test262StrictHandler.__test__ = False  # type: ignore[attr-defined]


I don't understand what this is for.

Because those handlers start with Test, the unit test runner thinks it is a test to run.

Without these lines completely, we get:

ERROR serve/test_serve.py::Test262WindowHandler - pytest.PytestCollectionWarning: cannot collect test class 'Test262WindowHandler' because it has a __init__ constructor... ERROR serve/test_serve.py::Test262WindowTestHandler - pytest.PytestCollectionWarning: cannot collect test class 'Test262WindowTestHandler' because it has a __init__ constru... ERROR serve/test_serve.py::Test262WindowModuleHandler - pytest.PytestCollectionWarning: cannot collect test class 'Test262WindowModuleHandler' because it has a __init__ const... ERROR serve/test_serve.py::Test262WindowModuleTestHandler - pytest.PytestCollectionWarning: cannot collect test class 'Test262WindowModuleTestHandler' because it has a __init__ c... ERROR serve/test_serve.py::Test262StrictWindowHandler - pytest.PytestCollectionWarning: cannot collect test class 'Test262StrictWindowHandler' because it has a __init__ const... ERROR serve/test_serve.py::Test262StrictWindowTestHandler - pytest.PytestCollectionWarning: cannot collect test class 'Test262StrictWindowTestHandler' because it has a __init__ c... ERROR serve/test_serve.py::Test262StrictHandler - pytest.PytestCollectionWarning: cannot collect test class 'Test262StrictHandler' because it has a __init__ constructor...

We ignore the attr-defined rule for these because, we will get these mypy errors otherwise:

tools/serve/test_serve.py:272: error: "type[Test262WindowHandler]" has no attribute "__test__" [attr-defined] tools/serve/test_serve.py:273: error: "type[Test262WindowTestHandler]" has no attribute "__test__" [attr-defined] tools/serve/test_serve.py:274: error: "type[Test262WindowModuleHandler]" has no attribute "__test__" [attr-defined] tools/serve/test_serve.py:275: error: "type[Test262WindowModuleTestHandler]" has no attribute "__test__" [attr-defined] tools/serve/test_serve.py:276: error: "type[Test262StrictWindowHandler]" has no attribute "__test__" [attr-defined] tools/serve/test_serve.py:277: error: "type[Test262StrictWindowTestHandler]" has no attribute "__test__" [attr-defined] tools/serve/test_serve.py:278: error: "type[Test262StrictHandler]" has no attribute "__test__" [attr-defined]

This is similar to this instance:

wpt/tools/wptrunner/wptrunner/tests/test_wptrunner.py

Lines 12 to 13 in 3d39e2d

TestQueueBuilder.__test__ = None # type: ignore[attr-defined]

TestRoot.__test__ = None # type: ignore[attr-defined]

or

this (but all mypy errors are ignored here)

wpt/tools/wptrunner/wptrunner/tests/test_wpttest.py

Lines 1 to 13 in 3d39e2d

# mypy: ignore-errors

from io import BytesIO

from unittest import mock

from manifest import manifest as wptmanifest

from manifest.item import TestharnessTest, RefTest

from manifest.utils import to_os_path

from . test_update import tree_and_sourcefile_mocks

from .. import manifestexpected, manifestupdate, wpttest

TestharnessTest.__test__ = False

Thanks! I realised what was probably going on right before looking at this review again. I think it's confusing enough to warrant a comment.

tools/serve/test_serve.py

jgraham

r+ with nit

jgraham · 2026-03-17T12:06:12Z

tools/serve/test_serve.py

+Test262WindowHandler.__test__ = False  # type: ignore[attr-defined]
+Test262WindowTestHandler.__test__ = False  # type: ignore[attr-defined]
+Test262WindowModuleHandler.__test__ = False  # type: ignore[attr-defined]
+Test262WindowModuleTestHandler.__test__ = False  # type: ignore[attr-defined]
+Test262StrictWindowHandler.__test__ = False  # type: ignore[attr-defined]
+Test262StrictWindowTestHandler.__test__ = False  # type: ignore[attr-defined]
+Test262StrictHandler.__test__ = False  # type: ignore[attr-defined]


Thanks! I realised what was probably going on right before looking at this review again. I think it's confusing enough to warrant a comment.

tools/serve/test_serve.py

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.

Co-authored-by: jgraham <[email protected]>

jcscottiii · 2026-03-17T20:44:41Z

The failing check is this:

=================================== FAILURES ===================================
_______________________ test_list_tests_missing_manifest _______________________

cls = <class '_pytest.runner.CallInfo'>
func = <function call_and_report.<locals>.<lambda> at 0x11a76d2d0>
when = 'call'
reraise = (<class '_pytest.outcomes.Exit'>, <class 'KeyboardInterrupt'>)

    @classmethod
    def from_call(
        cls,
        func: Callable[[], TResult],
        when: Literal["collect", "setup", "call", "teardown"],
        reraise: type[BaseException] | tuple[type[BaseException], ...] | None = None,
    ) -> CallInfo[TResult]:
        """Call func, wrapping the result in a CallInfo.
    
        :param func:
            The function to call. Called without arguments.
        :type func: Callable[[], _pytest.runner.TResult]
        :param when:
            The phase in which the function is called.
        :param reraise:

And it's only failing on Mac os x on a particular python version (whereas other versions passed). And it seems unrelated. Will merge.

…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.

wpt-pr-bot added infra serve labels Dec 18, 2025

wpt-pr-bot assigned jgraham Dec 18, 2025

wpt-pr-bot requested review from DanielRyanSmith, foolip, jgraham and jonathan-j-lee December 18, 2025 02:49

jcscottiii mentioned this pull request Dec 18, 2025

feat(runner): Integrate Test262 execution with wptrunner and add smoke tests [pt 3/5] #56842

Open

jcscottiii changed the title ~~feat(serve): Add server-side handlers for Test262 tests~~ feat(serve): Add server-side handlers for Test262 tests [pt 2/4] Dec 18, 2025

jcscottiii changed the title ~~feat(serve): Add server-side handlers for Test262 tests [pt 2/4]~~ feat(serve): Add server-side handlers for Test262 tests [pt 2/5] Dec 18, 2025

jcscottiii force-pushed the feat/test262-manifest-tooling branch from ad5fa6b to 72ff9c7 Compare December 18, 2025 14:01

jcscottiii force-pushed the feat/test262-serve-handler branch from 16aa645 to d5eb82e Compare December 18, 2025 14:05

This was referenced Dec 18, 2025

WIP: Test262 support #55997

Draft

Integrate Test262 into WPT web-platform-tests/rfcs#229

Merged

DanielRyanSmith approved these changes Dec 18, 2025

View reviewed changes

DanielRyanSmith reviewed Dec 18, 2025

View reviewed changes

jcscottiii force-pushed the feat/test262-serve-handler branch from d5eb82e to dcdca82 Compare December 19, 2025 17:56

jcscottiii force-pushed the feat/test262-serve-handler branch from dcdca82 to df146d5 Compare December 19, 2025 18:44

jgraham previously requested changes Dec 22, 2025

View reviewed changes

tools/serve/serve.py Outdated Show resolved Hide resolved

tools/serve/serve.py Show resolved Hide resolved

tools/serve/serve.py Outdated Show resolved Hide resolved

jcscottiii requested a review from jgraham January 27, 2026 16:00

DanielRyanSmith approved these changes Mar 12, 2026

View reviewed changes

jgraham requested changes Mar 16, 2026

View reviewed changes

wpt-pr-bot added the manifest label Mar 16, 2026

jcscottiii force-pushed the feat/test262-serve-handler branch from adef084 to 956ba8b Compare March 16, 2026 14:04

jgraham approved these changes Mar 17, 2026

View reviewed changes

Base automatically changed from feat/test262-manifest-tooling to master March 17, 2026 16:23

wpt-pr-bot added the wpt label Mar 17, 2026

jcscottiii and others added 8 commits March 17, 2026 16:27

do not use import alias for Test262 * in tests

2a44d62

address feedback

604d023

fix lint issues

1830c95

bring in changes from 56842

2cbdd6a

address feedback: module execution order

3f11064

refactor tests per @jgraham comment

ad3ee01

Update tools/serve/test_serve.py

1f27a1e

Co-authored-by: jgraham <[email protected]>

jcscottiii force-pushed the feat/test262-serve-handler branch from 12f7b3e to 1f27a1e Compare March 17, 2026 16:27

jcscottiii closed this Mar 17, 2026

jcscottiii reopened this Mar 17, 2026

jcscottiii merged commit 2fc4cd1 into master Mar 17, 2026
45 of 47 checks passed

jcscottiii deleted the feat/test262-serve-handler branch March 17, 2026 20:44

moz-wptsync-bot added mozilla:gecko-blocked and removed mozilla:gecko-blocked labels Mar 19, 2026

	TestQueueBuilder.__test__ = None # type: ignore[attr-defined]
	TestRoot.__test__ = None # type: ignore[attr-defined]

	# mypy: ignore-errors

	from io import BytesIO
	from unittest import mock

	from manifest import manifest as wptmanifest
	from manifest.item import TestharnessTest, RefTest
	from manifest.utils import to_os_path
	from . test_update import tree_and_sourcefile_mocks
	from .. import manifestexpected, manifestupdate, wpttest


	TestharnessTest.__test__ = False

Conversation

jcscottiii commented Dec 18, 2025

Uh oh!

DanielRyanSmith left a comment

Choose a reason for hiding this comment

Uh oh!

jcscottiii commented Dec 19, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jcscottiii commented Jan 27, 2026

Uh oh!

jcscottiii commented Mar 12, 2026

Uh oh!

DanielRyanSmith left a comment

Choose a reason for hiding this comment

Optimizations

Uh oh!

jcscottiii commented Mar 13, 2026

Optimizations

Uh oh!

jgraham Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

jcscottiii Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

jgraham Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jgraham left a comment

Choose a reason for hiding this comment

Uh oh!

jgraham Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jcscottiii commented Mar 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants