Because strtod need to set ERANGE and track the last character we have
to check the resulting value. We also have to check for nan and inf in
strtod itself as the new double parser doesn't accept that as floating
points.
This (and still some other methods) just say Expectation error leaving
the user completely in the dark whether the method threw at all.
And since we have nice function printing now we can just toString the
function since most are lambda's.
The implementations for these methods is manually defined in the .cpp
file for `int` and `float`, meaning that other `T` values would fail -
but only once we got to the linking stage. This patch makes the error
happen much earlier, so it's more obvious.
Putting the implementations in the .cpp file meant that they only
existed for `IntRect` and `FloatRect`, since those were instantiated at
the bottom of the file. Now they work for other types. :^)
A couple of places in WindowServer had to be modified to disambiguate
between the two `Rect::intersected()` overloads.
Co-authored-by: davidot <davidot@serenityos.org>
To use the `GET /session/{id}/element/{id}/css/{property name}`
WebDriver endpoint, two new IPC calls through the Browser are
implemented:
- get_active_documents_type returns the type of the active document,
which is either "xml" or "html"
- get_computed_value_for_element returns the computed CSS value (as
String) for the given element and CSS property name
It's potentially unsafe to access `m_root` in the destructor since it
may have been swept, so move unregistration of the NodeIterator into a
GC finalizer instead.
It's not safe to unregister ImageBox from the browsing context in the
destructor (since the browsing context may have already been swept and
destroyed).
Now that the layout tree is also GC-allocated, we can't be messing with
it from the DOM::Node destructor. Move everything to a GC finalizer
so we know it runs before the GC sweep phase.
Doing things in the destructor of a GC-allocated object isn't always
safe, in case it involves accessing other GC-allocated objects.
If they were already swept by GC, we'd be poking into freed memory.
This patch adds a separate finalization pass where GC calls finalize()
on every unmarked cell that's about to be deleted.
It's safe to access other GC objects in finalize(), even if they're
also unmarked.
Now that both the layout tree and browsing context are GC-allocated,
we can formalize their relationship a bit better by having layout
nodes keep a NonnullGCPtr to the browsing context.
This makes the previously-indirect link direct, removing an unpleasant
"how do we know the browsing context is alive" question when accessing
it from the layout tree.
This caused `Object.getOwnPropertyNames(window)` to throw, as the
`this` value is `Object`.
All users of document_tree_child_browsing_context_count call it on an
existing Window impl, including WP::internal_own_property_keys, so
getting the impl from the JS VM is not necessary.
Since SafeFunction strongly protects all of its captures, we can't
capture `this` when activating an event handler since that creates a
reference cycle and we end up leaking the entire world.
This removes a set of complex reference cycles between DOM, layout tree
and browsing context.
It also makes lifetimes much easier to reason about, as the DOM and
layout trees are now free to keep each other alive.
(And BrowsingContextGroup had to come along for the ride as well.)
This solves a number of nasty reference cycles between browsing
contexts, history items, and their documents.
This fixes an issue where GC would kill the internal realm if it ran at
the wrong time during startup. Found by aggressively GC'ing between
every allocation.
This prevents a reference cycle between a HTMLParser opened via
document.open() and the document. It was one of many things keeping
some documents alive indefinitely.
Due to the way we lazily construct prototypes and constructors for web
platform interfaces, it's possible for nested GC allocation to occur
while GC objects have been allocated but not fully constructed.
If the garbage collector ends up running in this state, it may attempt
to call JS::Cell::visit_edges() on an object whose vtable pointer hasn't
been set up yet.
This patch works around the issue by deferring GC while intrinsics are
being brought up. Furthermore, we also create a dummy global object for
the internal realm, and populate it with intrinsics. This works around
the same issue happening when allocating something (like the default UA
stylesheets) in the internal realm.
These solutions are pretty hacky and sad, so I've left FIXMEs about
finding a nicer way.
We were taking AK::Function and then passing them along to
NativeFunction, which takes a SafeFunction. This works, since
SafeFunction will transparently wrap AK::Function in a CallableWrapper
when assigned, but it was causing us to accumulate thousands of
pointless wrappers around direct function pointers.
By using SafeFunction at every step of the setup call chain, we no
longer create any CallableWrappers for the majority of native functions
in LibJS. Also, the number of heap-registered SafeFunctions in a new
realm goes down from ~5000 to 5. :^)
Instead of storing two JS::Handles into the DOM, we can combine them
into a single one.
If the layout node is anonymous, m_dom_node points to the DOM::Document.
Otherwise, m_dom_node points to the associated DOM node.
The anonymous state is moved to an m_anonymous boolean member.
This cuts the number of JS::Handles created by the layout tree in half
(and shrinks Layout::Node by 8 bytes).
When a new document becomes the active document of a browsing context,
we now notify the old document, allowing it to tear down its layout
tree. In the future, there might be more cleanups we'd like to do here.
Capturing a WeakPtr to a GC-allocated object in a JS::SafeFunction is
basically pointless, since the SafeFunction mechanism will then keep
the object alive anyway.
These functions were previously ad-hoc and returned the active
document's window. They now correctly teturn the browsing context's
WindowProxy instead.
