A tag tree is a data structure used for deserializing JPEG2000
packet headers.
We don't use them for anything yet, except from tests.
The implementation feels a bit awkward to me, but we can always polish
it later.
The spec thankfully includes two concrete examples. The code is
correct enough to pass those -- I added them as test.
If a DOM node isn't connected, there's no need to invalidate, since it's
not going to be visible anyway. The node will be automatically inserted
if/when it becomes connected in the future.
This step assumes copyURL is modified in place, while
`URL::Parser::basic_parse()` returns it as a result.
> 6. Basic URL parse input, with copyURL as url and fragment state as
state override.
So copyURL has to be reassigned to navigate to new url on step 8:
> 8. Location-object navigate this to copyURL.
- Reorder all the entries so their order match the corresponding specs.
- Add spec links for partial interfaces and mixins.
- Add FIXMEs for unimplemented APIs.
This changes the signature of queue_a_microtask() from AK:Function to
JS::HeapFunction to be more clear to the user of the functions that this
is what is used internally.
Makes some of the errors a bit less descriptive. But this is pretty
stable by now and the errors fire basically never, so that seems ok.
Needing the explicit `AK::` prefix is a bit awkward, but that'll go
away once this class moves out of LibPDF.
Move error() into the two subclasses. I'll remove it from CFF in
a follow-up.
No real behavior change.
Previously, calling fetch with a signal object provided by
`AbortSignal.timeout()` would cause a crash when the signal timed out.
We now push a `TemporaryExecutionContext` to the stack when we invoke
the signal's abort steps, as an execution context is required when
calling native functions.
Before this change we had to keep session history on browser side to
calculate a url for back/forward/reload action.
Now, with a mature enough implementation of navigation algorithms from
the specification, there is no need to use
history on the browser side to calculate navigation URLs because:
- Traversable navigable owns session history that is aware of all
navigations, including those initiated by History API and Navigation
API
- TraversableNavigable::traverse_the_history_by_delta() uses
traversable's history to calculate the next URL based on delta, so
there is no need for UI to keep sesion history.
In the future, we will likely want to add a way to pull session history
from WebContent to make it browsable from the UI.
The previous name was extremely misleading, because the call is used for
pushing or replacing new session history entry on chrome side instead of
only changing URL.
It is going to be used to communicate whether it is possible to navigate
back or forward after session history stored on browser side will no
longer be used to driver navigation.
