| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This patch moves the following things to being GC-allocated:
- Bindings::CallbackType
- HTML::EventHandler
- DOM::IDLEventListener
- DOM::DOMEventListener
- DOM::NodeFilter
Note that we only use PlatformObject for things that might be exposed
to web content. Anything that is only used internally inherits directly
from JS::Cell instead, making them a bit more lightweight.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Removing the FIXME'd code in b99cc7d was a bit too eager, and relying on
the main thread VM's current realm only works when JS is being executed.
Restore a simplified version of the old code to determine the realm this
time instead of the global object, following the assumptions already
made in get_current_value_of_event_handler() regarding what kind of
event target 'this' can be.
|
|
|
|
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 where the fun begins. :^)
|
|
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.
|
|
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.
|
|
|
|
This will allow us to remember an arbitrary origin instead of deriving
it from the document's URL.
|
|
|
|
...instead of doing a string compare on the DOCTYPE node.
|
|
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.
|
|
|
|
|
|
These circular imports led to the generator silently failing to
generate the required methods/properties.
|
|
|
|
|
|
Makes me wonder how things were working when Document was never
including GlobalEventHandlers.
|
|
|
|
This avoids slow RTTI lookups in selector matching.
|
|
This avoids slow RTTI lookups in Document::base_url().
|
|
This state is less static than we originally assumed, and there are
special formatting context-specific rules that say certain sizes are
definite in special circumstances.
To be able to support this, we move the has-definite-size flags from
the layout node to the UsedValues struct instead.
|
|
Absolutely positioned boxes are handled by the BFC destructor, so we
need to make sure the ICB BFC is destroyed if we want these boxes
to get laid out.
|
|
This is preparation for doing some more work when assigning to these
values.
|
|
This is a convenient way to return a DOM exception for operations that
return ErrorOr and only have an OOM failure path.
|
|
Step 19 of node removal was missing, which allows the mutations of the
descendants of the removed node to still be observed by the parent.
Step 20 of node removal queued the mutation record for the removed
node instead of it's parent. Since queuing takes place after the node
is removed from the tree, the mutation record would be lost as the only
inclusive ancestor of the node at this point is only the node itself.
|
|
This object contains all the CSS "used values" as seen during the layout
process, so calling it "used values" seems appropriate. :^)
|
|
This seems a bit more descriptive (and also a bit shorter).
|
|
Origin is defined in the HTML Standard, and therefore belongs into the
HTML directory and namespace in LibWeb.
https://html.spec.whatwg.org/multipage/origin.html#origin
|
|
This takes care of two FIXMEs and fixes an issue on Google Docs where
we'd mix boxes from different documents in the same layout tree.
(This happened because shadow trees remained attached to their old
document when their host was adopted.)
|
|
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
|
|
|
|
|
|
|
|
|
|
|
|
This makes it so that it always queues a mutation record, even if
`data` is set to the same value. It also makes it follow the spec
steps.
|
