Cookies have a minimum expiry resolution of 1 second. So to test cookie
expiration, the test had to idle for at least a second, which is quite a
noticeable delay now that LibWeb tests are parallelized.
Instead, we can add an internal API to expire cookies with a time offset
to avoid this idle delay.
This is necessary when we add more ServiceWorker capabilities, that
actually check this value. The more this spoof functionality is used,
the more we'll need to actually support serving test files over https.
Because of the previous awkward factoring of Origin we had two
implementations of Origin serializing and creation. Move the
implementation of DOMURL::url_origin into URL::origin, and
instead use the implemenation of URL::Origin::serialize for
serialization (replacing URL::serialize_origin).
This happens to fix 8 URL subtests as the two implemenations had
diverged, and URL::serialize_origin was previously missing the spec
changes of: whatwg/url@eee49fd and whatwg/url@fff33c3
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.
This API is a relic from the time when it was important for objects to
have easy access to the Window, and to know it was the global object.
We now have more spec-related concepts like relevant_global_object and
current_global_object to pull the Window out of thin air.
The drag-and-drop processing model allows for users to drag around
either elements within the DOM or objects completely outside the DOM.
This drag event can either end without action (via cancellation or user
input), or in a drop event, where the dragged object is dropped onto
another element within the DOM.
The processing model is rather large. This implements enough of it to
allow the UI process to specifically handle dragging objects outside of
the DOM onto the DOM. For example, dragging an image from the OS file
manager onto a file-upload input element. This does not implement the
ability to drag DOM elements.
This will allow fine grained control over animation times, which will
allow us to write timing tests that can reliably pass on the much slower
CI machines.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
This reverts commit e52c30cbd5.
It's highly possible that this test was flaky on CI due to mixing units
of seconds and milliseconds in the transient activation calculation.
Revert the workaround for that commit in an attempt to avoid needless
ad-hoc behavior.
We have a 5 second timeout between a user-activated event occurring and
an activation-gated API being invoked in order for that API to succeed.
This is quite fine in normal circumstances, but the machines used in CI
often exceed that limit (we see upwards of 10 seconds passing between
generating the user-activated event and the API call running).
So instead of generating a user-activated event, add a hook to allow
tests to bypass the very next activation check.
Hit-testing relies on updated clip rectangles and containing scroll
offsets, so it's necessary to ensure that paintables have these elements
updated.
This also removes the enclosing scroll offsets update from
`Internals::hit_test()`, as it is no longer needed.
Since we might enter Internals::hit_test() before the enclosing scroll
offsets are updated in the paintables tree during pre-paint, this
update need to be enforced.
We currently fire the change event on <input> elements when they lose
focus. The spec allows for us to also fire the event when changes are
"committed", so long as such an action makes sense for the input type.
This patch detects when the return key is entered in an <input> element
and uses that as the commit action for text-related types. If no change
has occurred since the last commit, no change event is fired.
With this change, we now have ~1200 CellAllocators across both LibJS and
LibWeb in a normal WebContent instance.
This gives us a minimum heap size of 4.7 MiB in the scenario where we
only have one cell allocated per type. Of course, in practice there will
be many more of each type, so the effective overhead is quite a bit
smaller than that in practice.
I left a few types unconverted to this mechanism because I got tired of
doing this. :^)
Some DOM APIs are restricted to user-activated events. For example, you
can't just invoke `navigator.clipboard.writeText` from JS - it has to be
accompanied by a user gesture, such as a mouse-down event. This adds an
Internals API to simulate such a gesture.
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.
This object is available as `window.internals` (or just `internals`) and
is only accessible while running in "test mode".
This first version only has one API: gc(), which triggers a garbage
collection immediately.
In the future, we can add more APIs here to help us test parts of the
engine that are hard or impossible to reach via public web APIs.