| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
GlobalObject is now a regular object with no special properties :^)
|
|
The protocol of the origin is used for checking if the a file://
iframe is allowed to be loaded (a document with a file:// origin
can load other files in iframes).
This used to be the case, but was changed in
6e71e400e696a92bbc2a69e6a59efddc29b926ce, which broke file:// iframes.
|
|
|
|
- Prefer VM::current_realm() over GlobalObject::associated_realm()
- Prefer VM::heap() over GlobalObject::heap()
- Prefer Cell::vm() over Cell::global_object()
- Prefer Wrapper::vm() over Wrapper::global_object()
- Inline Realm::global_object() calls used to access intrinsics as they
will later perform a direct lookup without going through the global
object
|
|
This is needed so that the allocated NativeFunction receives the correct
realm, usually forwarded from the Object's initialize() function, rather
than using the current realm.
|
|
|
|
|
|
Similar to create() in LibJS, wrap() et al. are on a low enough level to
warrant passing a Realm directly instead of relying on the current realm
from the VM, as a wrapper may need to be allocated while no JS is being
executed.
|
|
This is a continuation of the previous five commits.
A first big step into the direction of no longer having to pass a realm
(or currently, a global object) trough layers upon layers of AOs!
Unlike the create() APIs we can safely assume that this is only ever
called when a running execution context and therefore current realm
exists. If not, you can always manually allocate the Error and put it in
a Completion :^)
In the spec, throw exceptions implicitly use the current realm's
intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
|
|
This is a continuation of the previous three commits.
Now that create() receives the allocating realm, we can simply forward
that to allocate(), which accounts for the majority of these changes.
Additionally, we can get rid of the realm_from_global_object() in one
place, with one more remaining in VM::throw_completion().
|
|
This is a continuation of the previous two commits.
As allocating a JS cell already primarily involves a realm instead of a
global object, and we'll need to pass one to the allocate() function
itself eventually (it's bridged via the global object right now), the
create() functions need to receive a realm as well.
The plan is for this to be the highest-level function that actually
receives a realm and passes it around, AOs on an even higher level will
use the "current realm" concept via VM::current_realm() as that's what
the spec assumes; passing around realms (or global objects, for that
matter) on higher AO levels is pointless and unlike for allocating
individual objects, which may happen outside of regular JS execution, we
don't need control over the specific realm that is being used there.
|
|
|
|
|
|
|
|
|
|
|
|
Again, this is an entirely virtual class since the methods involve
direct access to the Painter. Though, maybe I could just expose the
Painter...
|
|
This one requires drawing to the canvas, so it doesn't make so much
sense to move the implementation over.
|
|
|
|
|
|
The implementation of this got a little funky, because it has to access
methods from CanvasState.
|
|
As with CanvasPath, this is to better match the spec IDL.
|
|
|
|
|
|
This better matches the spec, and makes it possible for things like
Path2D to reuse the same implementation without duplicate code. :^)
|
|
|
|
The changes from 8a03b17 to allow any JS::Value aren't a good fit, as
shown by the excessive amount of verify_cast needed :^)
|
|
|
|
This patch implements the "create a new browsing context" function from
the HTML spec and replaces our existing logic with it.
The big difference is that browsing contexts now initially navigate to
"about:blank" instead of starting out in a strange "empty" state.
This makes it possible for websites to create a new iframe and start
scripting inside it right away, without having to load an URL into it.
|
|
The way we've been creating DOM::Document has been pretty far from what
the spec tells us to do, and this is a first big step towards getting us
closer to spec.
The new Document::create_and_initialize() is called by FrameLoader after
loading a "text/html" resource.
We create the JS Realm and the Window object when creating the Document
(previously, we'd do it on first access to Document::interpreter().)
The realm execution context is owned by the Environment Settings Object.
|
|
|
|
This will be used to implement the rather intricate construction order
in the HTML spec.
|
|
This should really return the WindowProxy, but since we don't have the
infrastructure set up just yet, just return the window object itself
for now.
|
|
|
|
|
|
|
|
This is a cautious first step towards being able to create JS objects
before a global object has been instantiated.
|
|
This PageClient callback was never used for anything.
|
|
|
|
|
|
`Window` itself isn't generated from an IDL file so it doesn't get to
make use of this mixin, but it ideally would do so.
|
|
|
|
Also added FIXMEs for some missing methods while I was at it.
|
|
This avoids slow RTTI lookups in selector matching.
|
|
This avoids slow RTTI lookups in Document::base_url().
|
|
This disables this system progress bar, and instead creates one
out of pseudo elements, that can be selected and styled with the
::-webkit-progress-bar/value selectors.
|
