The window prototypes alert, confirm, and prompt must "pause" execution
until a response is received from the user. This test page is meant to
ensure that a timeout queued before a prompt is not executed until after
that prompt is closed.
Also added a local test for ensuring this behavior since it is unique to
browsers. Since we don't actually use WindowProxy anywhere yet we just
test on location for now.
Neither of the tests here actually passes properly right now. It's a
little more aspirational...
In the first one, the circle draws in the wrong place due apparently to
existing bugs in `CanvasRenderingContext2D::ellipse()`.
In the second, I just haven't yet implemented creating a Path2D from an
SVG path string, because that's going to take a fair bit of untangling
first.
Ensure we test both setTimeout and setInterval (and their cancellation
methods), and test scenarios such as raising exceptions in the callback,
passing extra arguments, etc.
Style updates are lazy since late last year, so the StyleInvalidator is
actually hurting us more than it's helping by running the entire CSS
selector machine on the whole DOM for every attribute change.
Instead, simply mark the entire DOM dirty and let the lazy style update
mechanism run *once* on next event loop iteration.
This tests the early return steps of "prepare a script" that come
_before_ step 10 "Set the element's "already started" flag". The
relevant steps are steps 6, 7 and 8. If this algorithm returns on any
of these steps, the script can be reinserted matching the requirements
and will run.
https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script
I wrote this test page up while testing something else, but found a bug
in Firefox where it doesn't allow re-preparing the script if step 8
fails: https://bugzilla.mozilla.org/show_bug.cgi?id=1735590
This patch adds a basic initial implementation of these API's.
Since LibWeb currently doesn't support workers, this implementation of
messaging doesn't bother with serializing and deserializing messages.
