Prevent premature stylesheet completion in script tests These tests check that a parser-inserted inline script executes the source captured during preparation, even if its text changes before execution. The CSP variant additionally checks that the source approved by CSP is the source that executes. To create a gap between preparation and execution, the tests put a pending stylesheet before the target script and schedule a timer to mutate its text. Previously, the mutation waited 500 ms and the stylesheet response waited one second. Those delays do not start together: speculative loading can request and finish the stylesheet while the parser is still waiting for testharness.js, before the mutation timer is even scheduled. The target script then executes before its text changes, producing a failure unrelated to the behavior under test. Keep the stylesheet response pending until the mutation callback explicitly releases it. This guarantees that stylesheet completion follows the mutation, regardless of when the stylesheet request starts. Use XHR for the release because Firefox explicitly exempts it from scheduling behind blocking CSS/JS loads; fetch() can instead deadlock this arrangement. Release the response even if the mutation step fails, so document loading can finish. This removes the premature-stylesheet-completion race, not every timing assumption. The existing 500 ms timer still assumes the parser has reached and prepared the target script before the mutation runs. Co-authored-by: codex <codex@openai.com>
The web-platform-tests Project is a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.
The most important sources of information and activity are:
wpt:matrix.org matrix channel; includes participants located around the world, but busiest during the European working day.If you'd like clarification about anything, don't hesitate to ask in the chat room or on the mailing list.
Clone or otherwise get https://github.com/web-platform-tests/wpt.
Note: because of the frequent creation and deletion of branches in this repo, it is recommended to “prune” stale branches when fetching updates, i.e. use git pull --prune (or git fetch -p && git merge).
See the documentation website and in particular the system setup for running tests locally.
The wpt command provides a frontend to a variety of tools for working with and running web-platform-tests. Some of the most useful commands are:
wpt serve - For starting the wpt http serverwpt run - For running tests in a browserwpt lint - For running the lint against all testswpt manifest - For updating or generating a MANIFEST.json test manifestwpt install - For installing the latest release of a browser or webdriver server on the local machine.wpt serve-wave - For starting the wpt http server and the WAVE test runner. For more details on how to use the WAVE test runner see the documentation.On Windows wpt commands must be prefixed with python or the path to the python binary (if python is not in your %PATH%).
python wpt [command]
Alternatively, you may also use Bash on Ubuntu on Windows in the Windows 10 Anniversary Update build, then access your windows partition from there to launch wpt commands.
Please make sure git and your text editor do not automatically convert line endings, as it will cause lint errors. For git, please set git config core.autocrlf false in your working tree.
The master branch is automatically synced to wpt.live and w3c-test.org.
Save the Web, Write Some Tests!
Absolutely everyone is welcome to contribute to test development. No test is too small or too simple, especially if it corresponds to something for which you've noted an interoperability bug in a browser.
The way to contribute is just as usual:
git checkout -b topic../wpt lint as described above.Use of LLMs to help author tests is generally acceptable, but every change must be attributable to a human who understands and can take responsibility for the proposed change.
Use of LLMs to participate in discussions is generally not acceptable; any LLM-generated content must either be from a bot account or contained inside a <blockquote> (for short contributions of at most one paragraph) or <details> element.
For full details see the Policy for LLM Use
If you spot an issue with a test and are not comfortable providing a pull request per above to fix it, please file a new issue. Thank you!