This is fixed by making the "about to be notified rejected promises
list" use JS::Handle instead of JS::NonnullGCPtr. This UAF happens
because notify_about_rejected_promises makes a local copy of this list,
empties the member variable list and then moves the local copy into a
JS::SafeFunction lambda. JS::SafeFunction can only see GC pointers that
are in its storage, not external storage.
Example exploit (requires fixed microtask timing by removing the dummy
execution context):
```html
<script>
Promise.reject(new Error);
// Exit the script block, causing a microtask checkpoint and thus
// queuing of a task to fire the unhandled rejection event for the
// above promise.
// During the time after being queued but before being ran, these
// promises are not kept alive. This is because JS::SafeFunction cannot
// see into a Vector, meaning it can't visit the stored NonnullGCPtrs.
</script>
<script defer>
// Cause a garbage collection, destroying the above promise.
const b = [];
for (var i = 0; i < 200000; i++)
b.push({});
// Some time after this script block, the queued unhandled rejection
// event task will fire, with the event object containing the dead
// promise.
window.onunhandledrejection = (event) => {
let value = event.promise;
console.log(value);
}
</script>
```
Instead of creating a new global object and proxying everything through
it, we now evaluate console inputs inside a `with` environment.
This seems to match the behavior of WebKit and Gecko in my basic
testing, and removes the ConsoleGlobalObject which has been a source of
confusion and invalid downcasts.
The globals now live in a class called ConsoleGlobalObjectExtensions
(renamed from ConsoleGlobalObject since it's no longer a global object).
To make this possible, I had to add a way to override the initial
lexical environment when calling JS::Interpreter::run(). This is plumbed
via Web::HTML::ClassicScript::run().
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
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 :^)
Before this change, each AST node had a 64-byte SourceRange member.
This SourceRange had the following layout:
filename: StringView (16 bytes)
start: Position (24 bytes)
end: Position (24 bytes)
The Position structs have { line, column, offset }, all members size_t.
To reduce memory consumption, AST nodes now only store the following:
source_code: NonnullRefPtr<SourceCode> (8 bytes)
start_offset: u32 (4 bytes)
end_offset: u32 (4 bytes)
SourceCode is a new ref-counted data structure that keeps the filename
and original parsed source code in a single location, and all AST nodes
have a pointer to it.
The start_offset and end_offset can be turned into (line, column) when
necessary by calling SourceCode::range_from_offsets(). This will walk
the source code string and compute line/column numbers on the fly, so
it's not necessarily fast, but it should be rare since this information
is primarily used for diagnostics and exception stack traces.
With this, ASTNode shrinks from 80 bytes to 32 bytes. This gives us a
~23% reduction in memory usage when loading twitter.com/awesomekling
(330 MiB before, 253 MiB after!) :^)
We can't be nuking the ESO while its owned execution context is still on
the VM's execution context stack, as that may lead to a use-after-free.
This patch solves this by adding a `context_owner` field to each context
and treating it as a GC root.
These lambdas were marked mutable as they captured a Ptr wrapper
class by value, which then only returned const-qualified references
to the value they point from the previous const pointer operators.
Nothing is actually mutating in the lambdas state here, and now
that the Ptr operators don't add extra const qualifiers these
can be removed.
This patch implements all changes to the specification touching the
subset of module script fetching we support.
Notably it adds parts of the specification for supporting import maps.
With this we are also able to get rid of a non standard workaround for a
spec issue we discovered while initially implementing module scripts :^)
This makes it polymorphic and allows checking the subclass of an
Environment with is<T>().
We also need to change the inheritance order so JS::Cell comes first for
this to work. Unfortunately, I have no idea why that is.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
(And BrowsingContextGroup had to come along for the ride as well.)
This solves a number of nasty reference cycles between browsing
contexts, history items, and their documents.
Print exceptions passed to `HTML::report_exception` in the JS console
Refactored `ExceptionReporter`: in order to report exception now
you need to pass the relevant realm in it. For passed `JS::Value`
we now create `JS::Error` object to print value as the error message.
We can now properly add the prototypes and constructors to the global
object of the Worker's inner realm, so we don't need this window for
anything anymore.
This patch adds a non standard step pushing the realm execution context
of fetching client's settings object onto the execution context stack
before linking a module script. Without the realm execution context
there is no current settings object, leading to a crash in
HostResolveImportedModule.
This patch adds various algorithms required to fetch and link module
scripts.
Some parts such as actually creating a request and error handling are
not implemented or use temporary non spec compliant code to get us
further.
Co-authored-by: davidot <davidot@serenityos.org>
This patchs adds the Web::HTML::Script subclass ModuleScript and
JavaScriptModuleScript as a type of ModuleScript as well as various
algorithms related to JavaScript module scripts.
Co-authored-by: davidot <davidot@serenityos.org>
This patch adds the ModuleMap class used to keep track of the type and
url of a module as well as the fetching state associated. Each
environment settings object now also has a module map.
These classes only needed Window to get at its realm. Pass a realm
directly to construct DOM and WebIDL classes.
This change importantly removes the guarantee that a Document will
always have a non-null Window object. Only Documents created by a
BrowsingContext will have a non-null Window object. Documents created by
for example, DocumentFragment, will not have a Window (soon).
This incremental commit leaves some workarounds in place to keep other
parts of the code building.
This Intrinsics object hangs off of a new HostDefined struct that takes
the place of EnvironmentSettingsObject as the true [[HostDefined]] slot
on JS::Realm objects created by LibWeb.
This gets the intrinsics off of the GlobalObject, Window, similar to the
previous refactor of LibJS to move the intrinsics into the Realm's
[[Intrinics]] internal slot.
A side effect of this change is that we cannot fully initialize a Window
object until the [[HostDefined]] slot has been installed into the realm,
which happens with the creation of the WindowEnvironmentSettingsObject.
As such, any Window usage that has not been funned through a WindowESO
will not have any cached Web prototyped or constructors, and will not
have Window APIs available to javascript code. Currently this seems
limited to usage of Window in the CSS parser, but a subsequent commit
will clean those up to take Realm as well. However, this commit compiles
so let's cut it off here :^).
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.
Workers don't have a document, so we can't ask them if scripting is
enabled or not. This is not the right long-term fix, but it fixes an
assertion when trying to query the missing responsible document of a
web worker.
This is *not* according to spec, however we currently store prototypes
and constructors on Window, so the only way for objects in a worker
context to become fully formed is to make a Window.
Long-term we should clean this up and remove the worker window object,
but for now it allows workers to exist without asserting.
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.
This removes the requirement of having a global object that actually
inherits from JS::GlobalObject, which is now a perfectly valid scenario.
With the upcoming removal of wrapper objects in LibWeb, the HTML::Window
object will inherit from DOM::EventTarget, which means it cannot also
inherit from JS::GlobalObject.
