With this change, we now have ~1200 CellAllocators across both LibJS and
LibWeb in a normal WebContent instance.
This gives us a minimum heap size of 4.7 MiB in the scenario where we
only have one cell allocated per type. Of course, in practice there will
be many more of each type, so the effective overhead is quite a bit
smaller than that in practice.
I left a few types unconverted to this mechanism because I got tired of
doing this. :^)
This algorithm is the meat of firing the NavigateEvent at navigation.
In order to implement it, we also need to add some getters/setters on
NavigateEvent. The implemetentation deviates from the spec in when
exactly the NavigateEvent is created. In following the pattern for other
events. we construct the event from the NavigateEventInit structure from
our native code. This makes the code a lot simpler than adding 10
getters to the NavigateEvent that are only ever used just after
construction. I'm not 100% conviced the promise resolution code is
correct, but we can add tests for that later :^).
These Navigation API Method Tracker AOs are called by the inner navigate
event firing algorithm. Implement them beforehand to make the diff look
pretty :^).
The potentially scroll/focus and finish AOs are called by the inner
navigate event firing algorithm. Implement them beforehand to make the
diff look pretty :^).
While we're here, assert that we're not doing this conversion when the
NavigationHistoryBehavior is still "auto", as the
HistoryHandlingBehavior enum is supposed to represent a "resolved"
behavior.
The proper abstract operations on Navigable and TraversableNavigable are
not quite ready to call from Navigation. With this commit all of the
user-facing APIs of Navigation are in place, and the stage should be set
to implement the parts of the navigation and traversal AOs that need to
interact with the Navigation object.
The implementation is incomplete, because our Navigable::navigate
implementation is missing the navigationAPIState parameter. We also
don't have Navigables hooked up completely enough to guarantee that a
fully active document that is not being unloaded always has a Navigable.
This API is how JavaScript can manipulate the new Navigable concepts
directly. We are still missing most of the interesting algorithms on
Navigation that do the actual navigation steps, and call into the
currently WIP navigable AOs.
