Previously it was not doing so, and some code relied on this not being
the case.
In particular, set_caption, set_t_head and set_t_foot in
HTMLTableElement relied on this. This commit is not here to fix this,
so I added an assertion to make it equivalent to a reference for now.
Nodes implementing the adoption steps can modify the passed in
document, for example HTMLTemplateElement does so to adopt it's
contents into the new document.
This will be used in HTMLTemplateElement later to clone template
contents.
This makes the clone functions non-const in the process, as the cloning
steps can have side effects.
It was directly creating a new Element object instead of creating the
appropriate element.
For example, document.body.cloneNode(true) would return an Element
instead of an HTMLBodyElement.
This allows you to invoke the HTML document parser and retrieve a
document as though it was loaded as a web page, minus any scripting
ability.
This does not currently support XML parsing.
This is used by YouTube (or more accurately, Web Components Polyfills)
to polyfill templates.
This is how the Web IDL spec defines it. We might eventually not need
native properties anymore, but that's another change for another day.
Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
This is a huge patch, I know. In hindsight this perhaps could've been
done slightly more incremental, but I started and then fixed everything
until it worked, and here we are. I tried splitting of some completely
unrelated changes into separate commits, however. Anyway.
This is a rewrite of most of Object, and by extension large parts of
Array, Proxy, Reflect, String, TypedArray, and some other things.
What we already had worked fine for about 90% of things, but getting the
last 10% right proved to be increasingly difficult with the current code
that sort of grew organically and is only very loosely based on the
spec - this became especially obvious when we started fixing a large
number of test262 failures.
Key changes include:
- 1:1 matching function names and parameters of all object-related
functions, to avoid ambiguity. Previously we had things like put(),
which the spec doesn't have - as a result it wasn't always clear which
need to be used.
- Better separation between object abstract operations and internal
methods - the former are always the same, the latter can be overridden
(and are therefore virtual). The internal methods (i.e. [[Foo]] in the
spec) are now prefixed with 'internal_' for clarity - again, it was
previously not always clear which AO a certain method represents,
get() could've been both Get and [[Get]] (I don't know which one it
was closer to right now).
Note that some of the old names have been kept until all code relying
on them is updated, but they are now simple wrappers around the
closest matching standard abstract operation.
- Simplifications of the storage layer: functions that write values to
storage are now prefixed with 'storage_' to make their purpose clear,
and as they are not part of the spec they should not contain any steps
specified by it. Much functionality is now covered by the layers above
it and was removed (e.g. handling of accessors, attribute checks).
- PropertyAttributes has been greatly simplified, and is being replaced
by PropertyDescriptor - a concept similar to the current
implementation, but more aligned with the actual spec. See the commit
message of the previous commit where it was introduced for details.
- As a bonus, and since I had to look at the spec a whole lot anyway, I
introduced more inline comments with the exact steps from the spec -
this makes it super easy to verify correctness.
- East-const all the things.
As a result of all of this, things are much more correct but a bit
slower now. Retaining speed wasn't a consideration at all, I have done
no profiling of the new code - there might be low hanging fruits, which
we can then harvest separately.
Special thanks to Idan for helping me with this by tracking down bugs,
updating everything outside of LibJS to work with these changes (LibWeb,
Spreadsheet, HackStudio), as well as providing countless patches to fix
regressions I introduced - there still are very few (we got it down to
5), but we also get many new passing test262 tests in return. :^)
Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
We must hook `on_call_stack_emptied` after the interpreter was created,
as the initialization of the WindowsObject can invoke some internal
calls, which will eventually lead to this hook being called without
`m_interpreter` being fully initialized yet.
Specifically, this now explicitly takes the length, adds missing
exceptions checks to calls with user-supplied lengths, takes and uses
the prototype argument, and fixes some spec non-conformance in
ArrayConstructor and its native functions around the use of ArrayCreate
This implements StringUtils::find_any_of() and uses it in
String::find_any_of() and StringView::find_any_of(). All uses of
find_{first,last}_of have been replaced with find_any_of(), find() or
find_last(). find_{first,last}_of have subsequently been removed.
Currently, each time parent_index() is invoked, two depth-first searches
are incurred to find the node's parent and grandparent. This becomes
particularly expensive, for example, when trying to scroll through a
large <ul> list.
Instead, upon creation, traverse the DOM JSON and create a map of child
nodes to their parent. Then those two lookups become hash map lookups
rather than a DFS traversal.
Currently, the DOM Inspector stores a numeric ID for each DOM node. This
is used to look up the data for that node in the JSON representation of
the DOM. The method to do this search performs a depth-first search
through the JSON value, and is invoked quite frequently.
Instead, we can just store a pointer to the JSON value in the index, and
avoid this search altogether. This is similar to how the IPWV stores a
pointer to the DOM node.
To improve the performance of the DOM Inspector when the Browser is run
in multi-process mode, do not create copies of the JSON values sent via
IPC when searching for a model index. Methods that are guaranteed to
return a value now return a reference. Methods that do not have such a
guarantee return a pointer (rather than an Optional, because Optional
cannot hold references).
The DOM Inspector performs well at first, but will start lagging again
once the tree is expanded a few nodes deep and/or with many nodes
visible in the tree.
This changes the m_parts, m_dirname, m_basename, m_title and m_extension
member variables to StringViews onto the m_string String. It also
removes the m_is_absolute member in favour of computing if a path is
absolute in the is_absolute() getter. Due to this, the canonicalize()
method has been completely rewritten.
The parts() getter still returns a Vector<String>, although it is no
longer a const reference as m_parts is no longer a Vector<String>.
Rather, it is constructed from the StringViews in m_parts upon request.
The parts_view() getter has been added, which returns Vector<StringView>
const&. Most previous users of parts() have been changed to use
parts_view(), except where Strings are required.
Due to this change, it's is now no longer allow to create temporary
LexicalPath objects to call the dirname, basename, title, or extension
getters on them because the returned StringViews will point to possible
freed memory.
The LexicalPath instance methods dirname(), basename(), title() and
extension() will be changed to return StringView const& in a further
commit. Due to this, users creating temporary LexicalPath objects just
to call one of those getters will recieve a StringView const& pointing
to a possible freed buffer.
To avoid this, static methods for those APIs have been added, which will
return a String by value to avoid those problems. All cases where
temporary LexicalPath objects have been used as described above haven
been changed to use the static APIs.
This introduces a new DOMTreeJSONModel, which provides the Model for the
InspectorWidget when the Browser is running using the
OutOfProcessWebView.
This Model is constructed with a JSON object received via IPC from the
WebContentServer.
Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to
WebContentClient.
These two async methods form a request & response for requesting a JSON
representation of the Content's DOM tree.
This method builds a JSON object representing the full state of the
DOM tree.
The JSON that is built will be used for building the DOM Inspector
widget for the OutOfProcessWebView.
This removes JsonObject::get_or(), which is inefficient because it has
to copy the returned value. It was only used in a few cases, some of
which resulted in copying JsonObjects, which can become quite large.
The WebIDL spec specifies a few "simple" exception types in addition to
the DOMException type, let's support all of those.
This allows functions returning ExceptionOr<T> to throw regular
javascript exceptions (as limited by the webidl spec) by returning a
`DOM::SimpleException { DOM::SimpleExceptionType::T, "error message" }`
which is pretty damn cool :^)
Adds support for the :active pseudo-class for hyperlinks (<a> tags
only).
Also, since it was very similar to :focus and an element having a
focused state was already implemented, I went ahead and implemented
that pseudo-class too, although I cannot come up with a working
example to validate it.
