Imported WPT tests often load resources using canonical absolute paths,
for example:
/html/browsers/windows/resources/message-parent.html
Our usual strategy is to rewrite such URLs to relative paths during
import so they resolve from the importing test HTML file (which also
allows for loading this HTML as a file://).
That works for same-origin relative loading with the echo server, but it
breaks down when a test constructs a cross-origin URL from an absolute
path, for example:
get_host_info().REMOTE_ORIGIN + "/some/wpt/path.html"
In that case the resource still needs to be fetched at its canonical
absolute path, so rewriting it relative to the importing document is no
longer sufficient.
Update the HTTP test server so /static/ continues to serve from the
general test root, other non-echo requests are served from the imported
WPT tree, and dynamically registered echo responses live under /echo/
to avoid path conflicts.
A test configured under LoadFromHttpServer is loaded over localhost
rather than 127.0.0.1, causing the echo server to be accessed
across origins. In general, the behavior being tested is intended
for same-origin scenarios, so update the echo server URL to use
localhost.
This fixes slow test execution on macOS where localhost resolution
has a 200ms delay due to IPv6 fallback behavior in libcurl.
The XMLHttpRequest-override-mimetype-blob.html test now runs in ~0.6s
instead of ~16s on macOS.
Fixes#4850
See also: https://github.com/curl/curl/issues/2281
This catches errors that occur within async tests so that we fail faster
rather than timing out due to `done()` not being called.
We use `Promise.resolve()` because `f` isn't guaranteed to be an async
function.
This commit makes the following changes:
- Adds a model "Echo" for the request body
- Changes the main endpoint from /create to /echo (more REST-y)
- Sends "400: Bad Request" for invalid params or a reserved path
- Sends "409: Conflict" when trying to use an already registered path
- Prints the server port to stdout
- Removes unnecessary subcommands/options (start, stop, --background)
The example shows how to write a test that depends on custom HTTP
headers in the response. This will be useful for testing browser JS
that depends on how Ladybird processes response headers, eg CORS
headers like Access-Control-Allow-Origin and others.
Previously, if there was an unhandled exception in an async test, it
might fail to call done() and timeout. Now we have a default "error"
handler to catch unhandled exceptions and fail the test. A few tests
want to actually test the behavior of window.onerror, so they need an
escape hatch.
For example, in the following abbreviated test HTML:
<span>some text</span>
<script>println("whf")</script>
We would have to craft the expectation file to include the "some text"
segment, usually with some leading whitespace. This is a bit annoying,
and makes it difficult to manually craft expectation files.
So instead of comparing the expectation against the entire DOM inner
text, we now send the inner text of just the <pre> element containing
the test output when we invoke `internals.signalTextTestIsDone`.
This is not that easy to use for test developers, as forgetting to set
the url back to its original state after testing your specific API will
cause future navigations to fail in inexplicable ways.
Calling test() multiple times in the same test file is not actually
valid, and can cause the following test to hang forever. So let's stop
doing that in the one test that did so, and also prevent the same
mistake happening again. :^)
Throwing an exception on subsequent test() calls means that we don't
hang, the test will fail with missing output, and we get a log message
explaining why.
Previously, we used `on_load_finish` to determine when the text test
was completed. This method did not allow testing of async functions
because there was no way to indicate that the runner should wait for
the async call to end.
This change introduces a function in the `internals` object that is
intended to be called when the text test execution is completed. The
text test runner will now ignore `on_load_finish` which means a test
will timeout if this new function is never called.
`test(f)` function in `include.js` has been modified to automatically
terminate a test once `load` event is fired on `window`.
new `asyncTest(f)` function has been introduces. `f` receives function
that will terminate a test as a first argument.
Every test is expected to call either `test()` or `asyncTest()` to
complete. If not, it will remain hanging until a timeout occurs.
Although we translate e.g `block` to `block flow` for internal use in
the engine, CSS-DISPLAY-3 tells us to use the short form in
serializations for compatibility reasons.
This adds 9 points to our score on https://html5test.com/ :^)
