Age | Commit message (Collapse) | Author |
|
|
|
This helps us to get from a Window to the containing Page, without
clients having to go through Document.
|
|
This better matches the spec nomenclature. Note that we don't yet
*retrieve* the active document according to spec.
|
|
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.
|
|
This is the "browsing context container document" from the spec.
|
|
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 will be required for event loop processing.
|
|
There are three types of event loop: window, worker and worklet.
For now, we only have window event loops.
|
|
|
|
|
|
|
|
|
|
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.
|
|
This is not a functional change, it merely reorders operations so that
we match spec language better.
|
|
|
|
This fixes a long-standing bug where the view wouldn't update when
navigating to a new page after looking at the ACID2 test. This happened
because ACID2 actually scrolls the viewport far down. We didn't reset
the scroll position upon navigation, and so the new page thought that
we were still scrolled very far down, and this broke the invalidation
rect calculations.
|
|
The "Box" suffix added nothing here.
|
|
At the moment, nested browsing contexts expect that there's always a
top-level browsing context at some higher level. That's okay, but let's
keep the top-level pointer in a WeakPtr to make it easier to catch
mistakes (as this turns UAF into a null dereference.)
|
|
|
|
Names are still catching up after the Frame => BrowsingContext rename.
|
|
|
|
The real class is Web::Layout::StackingContext.
|
|
|
|
This avoids having two nearly-identical initializer lists and and an
awkward setup() function that every constructor must call.
|
|
This required adding a simple OOPWV::dump_layout_tree() API that
synchronously requests a dump of the layout tree from the WebContent
process.
|
|
This also does some east-const changes in TreeNode.
|
|
No major engine allows whitespace in the type when checking for
"module".
This was also reflected in the relevant web platform test, but not in
the spec.
The spec has been changed to match this behaviour: https://github.com/whatwg/html/commit/23c723e3e94103e495a6b67e60ffc8a1a164334b
|
|
|
|
This patch removes the following WebContent IPC calls, which are no
longer used:
- `Server::js_console_initialize()`
- `Client::did_js_console_output()`
|
|
This patch introduces three new IPC calls for WebContent:
- `Client::did_output_js_console_message(index)`:
Notifies the client that a new console message was logged.
- `Server::js_console_request_messages(start_index)`:
Ask the server for console messages starting at the given index.
- `Client::did_get_js_console_messages(start_index, types, messages)`:
Send the client the messages they requested.
This mechanism will replace the current
`Client::did_js_console_output()` call in the next few commits. This
will allow us to display messages in the console that happened before
the console was opened.
|
|
The current implementation felt a bit ad-hoc and notably allowed
textContent to operate on all node types. It also only returned the
child text content of the Node instead of the descendant text content.
|
|
|
|
See https://dom.spec.whatwg.org/#characterdata
|
|
These three nodes are the only nodes in the DOM spec with constructors.
|
|
|
|
|
|
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
|
|
See https://github.com/whatwg/html/commit/33ff054a6caa014f4cce2912c93a19547a2e2717
|
|
|
|
And also try_create<T> => try_make_ref_counted<T>.
A global "create" was a bit much. The new name matches make<T> better,
which we've used for making single-owner objects since forever.
|
|
This was accidentally missing ".root()": "or parent is a node and
target’s _root_ is a shadow-including inclusive ancestor of parent"
https://dom.spec.whatwg.org/#concept-event-dispatch Step 5.9.6
|
|
The root of a node can never be null, as "the root of an object is
itself, if its parent is null, or else it is the root of its parent."
https://dom.spec.whatwg.org/#concept-tree-root
|
|
This is needed for the "Inspect Element" context menu action.
|
|
This lets us "push" a new style-properties list to the DOM Inspector,
for example when JS changes the style of the inspected node.
|
|
This is the IPC version of `Document::set_inspected_node()`, using a
node ID.
We return the inspected node's style properties as JSON, so that the DOM
Inspector can immediately display them.
|