We previously used an empty optional to denote that a ReferrerPolicy is
in the default empty string state. However, later additions added an
explicit EmptyString state. This patch moves all users to the explicit
state, and stops using `Optional<ReferrerPolicy>` everywhere except for
when an option not being passed from JavaScript has meaning.
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 commit removes DeprecatedString's "null" state, and replaces all
its users with one of the following:
- A normal, empty DeprecatedString
- Optional<DeprecatedString>
Note that null states of DeprecatedFlyString/StringView/etc are *not*
affected by this commit. However, DeprecatedString::empty() is now
considered equal to a null StringView.
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.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
This allows the garbage collector to keep HTML::Script objects alive and
fixes a bug where a HTMLScriptElement could get GC'd while its code was
executing.
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.
We shouldn't delay the load event for scripts that we're completely
refusing to run anyway. Also, for scripts that have inline text content,
we don't need to delay them either, as they will become ready before
returning from "prepare script".
This makes the "load" event finally fire on lots of websites, including
Wikipedia. :^)
We previously had a bug where markup with unclosed script tags caused
the document load event to be delayed indefinitely. Fix this by only
marking script elements as delaying the load event once we encounter
the script end tag.
Before this patch, HTMLScriptElement would cache the full script source
text in a String member, and parse that just-in-time via Document's
run_javascript() helpers.
We now follow the spec more closely and turn the incoming source text
into a ClassicScript object ("the script's script" in the spec.)
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
Also updates the "inserted_into" function as per the previous commit.
Changes the FIXME, as according to the spec there is no notification
system to be notified of things such as the node becoming connected.
Instead, "becomes connected" means when the insertion steps are run,
the element is now connected when it previously wasn't.
https://html.spec.whatwg.org/multipage/infrastructure.html#becomes-connected
This is done in this PR because the insertion steps are run when the
start tag is inserted. This made it try to prepare the script too early
for inline scripts.
The order of operations in the HTML document parser ensures that
the parser document is set before the insertion steps are run.
There's a bit more nuance to how this should really work, but let's at
least make sure we execute <script> elements if you insert them into
the document.
This fills in a bunch of the FIXMEs that was in prepare_script.
execute_script is almost finished, it's just missing the module side.
As an aside, let's not assert when inserting a script element with
innerHTML.
