Similar to create() in LibJS, wrap() et al. are on a low enough level to
warrant passing a Realm directly instead of relying on the current realm
from the VM, as a wrapper may need to be allocated while no JS is being
executed.
Step 19 of node removal was missing, which allows the mutations of the
descendants of the removed node to still be observed by the parent.
Step 20 of node removal queued the mutation record for the removed
node instead of it's parent. Since queuing takes place after the node
is removed from the tree, the mutation record would be lost as the only
inclusive ancestor of the node at this point is only the node itself.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
Used by Google seemingly almost all around account sign in and
management. The modern sign in page has this near the beginning:
```html
<base href="https://accounts.google.com">
```
All of the XHRs performed by sign in are relative URLs to this
base URL. Previously we ignored this and did it relative to the
current URL, causing the XHRs to 404 and sign in to fall apart.
I presume they do this because you can access the sign in page
from multiple endpoints, such as `/ServiceLogin` and
`/o/oauth2/auth/identifier`
- Don't add multiple numbers to nested steps, just the innermost one
(as rendered in the HTML document)
- "Otherwise" comments go before the else, not after it
- "FIXME:" goes before step number, not between it and the comment text
- Always add a period between number and comment text
The majority of these were introduced in #13756, but some unrelated ones
have been updated as well.
This is now the source of truth for 'user enabled/disabled scripting',
but it has to ask the window's page, which actually stores the setting.
Also use this new functionality in two places where it was previously
marked as a FIXME.
There's no need to have a custom is_scripting_enabled() for the
Document class, as it (indirectly) inherits from Node.
Also, let's not hardcode false here :^)
Add a flag to DOM::Document that means the whole document needs a style
update. This saves us the trouble of traversing the entire DOM to mark
all nodes as needing a style update.
We were not actually walking past the first ancestor when setting
child-needs-update bit upwards.
Also, let's walk all the way to the root, even if there's a
child-needs-update bit already set. This ensures that we always leave
this function with the ancestor chain in a sane state.
- Access members directly instead of going through accessors,
avoiding a lot of redundant traversal done by accessors.
- Cross shadow boundaries and make sure that shadow trees get their
dirty bits updated as well.
- Do the minimum amount of traversal needed when setting the "child
needs style update" bit upwards through ancestors.
Before this change, style invalidation didn't propagate upwards across
shadow boundaries, so our shadow trees were sitting there with invalid
style, never actually getting updated.
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
The "paintable" state in Layout::Box was actually not safe to access
until after layout had been performed.
As a first step towards making this harder to mess up accidentally,
this patch moves painting information from Layout::Box to a new class:
Painting::Box. Every layout can have a corresponding paint box, and
it holds the final used metrics determined by layout.
The paint box is created and populated by FormattingState::commit().
I've also added DOM::Node::paint_box() as a convenient way to access
the paint box (if available) of a given DOM node.
Going forward, I believe this will allow us to better separate data
that belongs to layout vs painting, and also open up opportunities
for naturally invalidating caches in the paint box (since it's
reconstituted by every layout.)
This forces us to recompute style everywhere, since all kinds of
selectors may produce different results now.
In the future, we should look at narrowing down the invalidation that
occurs here, but for now let's just invalidate everything and make the
results correct before worrying about performance.
These steps run when a node is about to be removed from its parent,
and adjust the position of any live NodeIterators so that they don't
point at a now-removed node.
Note that while this commit implements what's in the DOM specification,
the specification doesn't fully match what other browsers do.
Spec bug: https://github.com/whatwg/dom/issues/907
Instead of just the outline, fill them with some semi-transparent color.
Also add tag name, ID, classes and coordinates to the little tooltip.
Finally, use the border box instead of the context box for metrics,
same as other browsers.
I can't imagine how this happened, but it seems we've managed to
conflate the "event listener" and "EventListener" concepts from the DOM
specification in some parts of the code.
We previously had two things:
- DOM::EventListener
- DOM::EventTarget::EventListenerRegistration
DOM::EventListener was roughly the "EventListener" IDL type,
and DOM::EventTarget::EventListenerRegistration was roughly the "event
listener" concept. However, they were used interchangeably (and
incorrectly!) in many places.
After this patch, we now have:
- DOM::IDLEventListener
- DOM::DOMEventListener
DOM::IDLEventListener is the "EventListener" IDL type,
and DOM::DOMEventListener is the "event listener" concept.
This patch also updates the addEventListener() and removeEventListener()
functions to follow the spec more closely, along with the "inner invoke"
function in our EventDispatcher.
This isn't perfect (especially the global object situation in
activate_event_handler), but I believe it's in a much more complete
state now :^)
This fixes the issue of crashing in prepare_for_ordinary_call with the
`i < m_size` crash, as it now uses the IDL callback functions which
requires the Environment Settings Object. The environment settings
object for the callback is fetched at the time the callback is created,
for example, WrapperGenerator gets the incumbent settings object for
the callback at the time of wrapping. This allows us to remove passing
in ScriptExecutionContext into EventTarget's constructor.
With this, we can now drop ScriptExecutionContext.
Instead of making each Layout::Node compute style for itself, we now
compute it in TreeBuilder before even calling create_layout_node().
For non-element DOM nodes, we create the style and layout tree node
in TreeBuilder. This allows us to move create_layout_node() from
DOM::Node to DOM::Element.
This changes allows for nested browser contexts to be embedded in the
serialized JSON of their container element (like `iframe`) and enables
their inspection in the DOM Inspector.
Use a simple heuristic to exclude uninteresting whitespace and
de-clutter the inspector's DOM tree.
Uninteresting whitespace is currently one of these:
- Non-rendered whitespace-only text nodes
- Rendered whitespace-only text nodes between block-level elements
Since style update is driven by Document, moving a node with dirty style
from one document to another means that we have to schedule a style
update in the new document.
Instead of doing layout synchronously whenever something changes,
we now use a basic event loop timer to defer and coalesce relayouts.
If you did something that requires a relayout of the page, make sure
to call Document::set_needs_layout() and it will get coalesced with all
the other layout updates.
There's lots of room for improvement here, but this already makes many
web pages significantly snappier. :^)
Also, note that this exposes a number of layout bugs where we have been
relying on multiple relayouts to calculate the correct dimensions for
things. Now that we only do a single layout in many cases, these kind of
problems are much more noticeable. That should also make them easier to
figure out and fix. :^)
