Problem: Holding form.elements while the form is detached + dropped hit
a use-after-free: the form is GC’ed while the collection’s still live.
Cause: HTMLCollection (and LiveNodeList too) was storing its filter as
an AK::Function — which the garbage collector doesn’t visit. When a
filter lambda captures a GC object (e.g. the form in form.elements) that
object has no GC edge keeping it alive. So it can be collected while the
collection using it’s still reachable — leaving a dangling pointer.
Fix: HTMLCollection and LiveNodeList are GC cells with their own
visit_edges. So, visit the filter’s (and sort’s) capture range there:
conservatively mark any GC object a captured lambda holds — to ensure
it’s kept alive as long as the collection’s reachable.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/9948
Similar to GC::Root<T>, make GC::RootVector<T> constructible without
explicitly passing a Heap.
This is implemented by having RootVectorBase use GC::Heap::the() for
heap-free construction.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
