This fixes#9978.
When a TokenStream is empty, reading its `current_token()` still returns
a token (for EOF) so it makes sense to allow users to
`reconsume_current_input_token()` that token, so they do not have to
handle that themselves. Instead of VERIFY()ing, we can just no-op when
reconsuming token 0.
There were a few calls to the standalone version of dump_tree() inside
the recursive version of dump_tree(), which led to the output getting
jumbled out of order.
This is the result of debugging React DOM, which would throw a TypeError
when assigning to window.event in strict mode and then not complete
rendering - here:
cae6350/packages/shared/invokeGuardedCallbackImpl.js (L134)
With this change, the following minimal React example now works!
<div id="app"></div>
<script src="react.development.js"></script>
<script src="react-dom.development.js"></script>
<script>
ReactDOM.render(
React.createElement("h1", null, "Hello World"),
document.getElementById("app")
);
</script>
The [Replaceable] attribute "indicates that setting the corresponding
property on the platform object will result in an own property with the
same name being created on the object which has the value being
assigned. This property will shadow the accessor property corresponding
to the attribute, which exists on the interface prototype object."
(https://heycam.github.io/webidl/#Replaceable)
The spec doesn't tell how exactly this is supposed to be done, but other
engines just have a setter as well that just redefines the property
as a data descriptor when called, and returns undefined.
It's bound to the property name and requires an object of the correct
type, so I mirrored these constraints here. Storing the setter and
calling it multiple times will therefore just work.
Implementing this in the wrapper generator is left as an exercise for
the reader, this is going to be used in WindowObject, which isn't
generated from IDL yet.
We need both a GlobalObject and Realm now, but can get the former from
the latter (once initialized).
This also fixes JS execution in LibWeb, as we failed to set the Realm of
the newly created Interpreter in this function.
The spec allows us to optionally return from these for any reason.
Our reason is that we don't have all the infrastructure in place yet to
implement them.
... and `Window.scrollTo()`, which is an alias for `scroll()`.
There is still work that needs to be done here, regarding bringing the
scroll position calculation in line with the spec. Currently we get the
viewport rect from outside, and treat it as if it was the result of
calculating steps 5-9 of the `scroll()` method. But it works. :^)
This is in preparation for implementing JS scrolling functions, which
specify both x and y scrolling deltas. The visible behavior has not
changed.
Also, moved the "mouse wheel delta * 20" calculation to the
`EventHandler` since the JS calls will want to work directly in pixels.
This just returns an empty CSSStyleDeclaration for now. The real thing
needs to be a live object that provides a view onto the computed style
of a given element. This is far from that, but it's something. :^)
Any browsing context that doesn't have a parent browsing context is now
considered a top-level browsing context. This matches the HTML spec.
This means we no longer keep a pointer to the top-level context, since
we can simply walk the parent chain until we find the topmost ancestor.
Before this patch, HTMLScriptElement would cache the full script source
text in a String member, and parse that just-in-time via Document's
run_javascript() helpers.
We now follow the spec more closely and turn the incoming source text
into a ClassicScript object ("the script's script" in the spec.)
Let's err on the side of caution and use a WeakPtr instead of a
DOM::Document&. Even if the object lifetimes involved here should be
well-defined, they are fairly complicated.
Call HTML::EventLoop::spin_until() from the HTML parser when deciding
whether we can run a script yet.
Note that spin_until() actually doesn't do any work yet.
This will be used by the HTML parser to determine whether it's okay to
start running a script.
Note that we don't actually count the script-blocking style sheets yet.
This patch only adds a the checking mechanism for the parser.
We already have a base class for frame elements that we call
BrowsingContextContainer. This patch makes BrowsingContext::container()
actually return one of those.
This makes us match the spec names, and also solves a FIXME about having
a shared base for <frame> and <iframe>. (We already had the shared base,
but the pointer we had there wasn't tightly typed enough.)
This roughly models the "queue an element task" algorithm from the spec.
For safety, this captures a strong reference to the element, and then
bundles that with a callback into a HTML::Task (that we then queue up.)
Since we can't simply give HTML::EventLoop control of the whole program,
we have to integrate with Core::EventLoop.
We do this by having a single-shot 0ms Core::Timer that we start when
a task is added to the queue, and restart after processing the queue and
there are still tasks in the queue.
This patch attaches a HTML::EventLoop to the main thread JS::VM used
for JavaScript bindings in the web engine.
The goal here is to model the various task scheduling mechanisms of the
HTML specification.
