DOMMatrix fromMatrix was using create_from_dom_matrix_2d_init to make
a DOMMatrix for it's init struct this is wrong because only the 2D
params of the DOMMatrix are put into the new matrix. I have added
a non 2D version of that function that takes the full DOMMatrixInit
so now fromMatrix works correctly again. I also have added some
text tests to test if it works correctly.
I split the dommatrix.html text tests into multiple files because that
file was becoming to big so now every sub function is a seperate file.
NewAKString is effectively the default for any new IDL interface, so
let's mark this as the default behavior. It also makes it much easier to
figure out whatever interfaces are still left to port over to new AK
String.
The matrix used in the spec is column-major but Gfx::Matrix4x4 is
row-major so we need to transpose the values. This will fix internal
operations on that matrix. Because we also transposed the readonly
matrix property getters the matrix is again transposed when reading
so the JavaScript world only sees a column-major matrix.
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
With the GC heap conversion, the functionality of legacy platform
objects was broken. This is because the generated implementation of one
of them was used for all of them, removing functionality such as
deletion.
This re-adds all functionality, where questions such as "does the
object support indexed properties?" is instead answered by virtual
functions instead of by the IDL generator checking the presence of
certain keywords/attributes.
Note that as of this commit, there aren't any such throwers, and the
call site in Heap::allocate will drop exceptions on the floor. This
commit only serves to change the declaration of the overrides, make sure
they return an empty value, and to propagate OOM errors frm their base
initialize invocations.
This needs to happen before prototype/constructor intitialization can be
made lazy. Otherwise, GC could run during the C++ constructor and try to
collect the object currently being created.
The intent is to use these to autogenerate prototype declarations for
Window and WorkerGlobalScope classes.
And the spec links are just nice to have :^)
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
