| Age | Commit message (Collapse) | Author |
|---|
|
This implementation only works for cloning Numbers, and does not try to
do all the spec steps for structured serialize and deserialize.
Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
|
|
Still some TODOs here:
* We don't handle all capabilities (e.g. proxy)
* We don't match the capabilities against the running browser
But this will parse the capabilities JSON object received from the
WebDriver client.
|
|
This patch adds basic DOM construction and IDL bindings for foreign
objects in SVG trees.
|
|
This moves communication and route matching for WebDriver endpoints into
LibWeb. This is to reduce the amount of duplication required to create a
WebDriver implementation for Ladybird.
In doing so, this introduces some cleanup of WebDriver handling. Routes
are now a compile-time array, and matching a route is nearly free of
allocations (we still allocate a Vector for parsed parameters). This
implementation also makes heavier use of TRY semantics to propagate
errors into one handler.
|
|
|
|
This will allow for implementing the screenshot action closer to the
spec, as we can now use HTMLCanvasElement to encode the bitmap, and
capture the screenshot on the animation frame loop.
|
|
|
|
This is essentially an ErrorOr<JsonValue, Web::WebDriver::Error> class.
Unfortunately, that ErrorOr would not be default-constructible, which is
required for the generated IPC classes. So this is a thin wrapper around
a Variant<JsonValue, Web::WebDriver::Error> to emulate ErrorOr.
|
|
This is to prepare for WebContent becoming the WebDriver client.
|
|
The (un)focus steps have no dependency on HTMLElement, thus we can
extract them into their own file. This allows them to be called
anywhere.
|
|
This cannot be done on the Browser or WebDriver ends, or via the
existing run_javascript() IPC endpoint, as we cannot transfer JS objects
through the IPC boundary (yet), only serialized JSON, so the individual
WebDriver steps around script execution need to run in the WebContent
process.
|
|
Otherwise, we end up propagating those dependencies into targets that
link against that library, which creates unnecessary link-time
dependencies.
Also included are changes to readd now missing dependencies to tools
that actually need them.
|
|
With so much infrastructure implemented, we can finally add the last
piece of this puzzle - the fetch() method itself!
This contains a few hundred lines of generated code as handling the
RequestInfo and RequestInfo parameter types manually is not feasible,
but we can't use the IDL definition as the Window object is handwritten
code at the moment.
It's neatly tucked away in Bindings/ and will be removed eventually.
|
|
This implements the following operations from section 4 of the Fetch
spec (https://fetch.spec.whatwg.org/#fetching):
- Fetch
- Main fetch
- Fetch response handover
- Scheme fetch
- HTTP fetch
- HTTP-redirect fetch
- HTTP-network-or-cache fetch (without caching)
It does *not* implement:
- HTTP-network fetch
- CORS-preflight fetch
Instead, we let ResourceLoader handle the actual networking for now,
which isn't ideal, but certainly enough to get enough functionality up
and running for most websites to not complain.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Get rid of the bespoke NavigatorObject class and use the modern IDL
strategies for creating platform objects to re-implement Navigator and
its associcated mixin interfaces. While we're here, implement it in a
way that brings WorkerNavigator up to spec :^)
|
|
|
|
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.
|
|
This is being used for more than just time coarsening now, so let's use
the spec's section title for the name.
|
|
|
|
...and make it spec compliant by considering all ASCII whitespace,
greatly simplifying it in the process :^)
|
|
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 will be used to share functionality between Request and Response.
|
|
|
|
|
|
|
|
Until now, we've been using CSS::LengthPercentage, sometimes wrapped in
Optional, to represent CSS sizes.
This meant we could not support modern values like `min-content`,
`max-content`, `fit-content(<length>)`. We were also conflating `none`
and `auto` which made the `min-*` and `max-*` properties confusing.
The new CSS::Size class covers all possible size values as individual
substates. It'll be quite a bit of work to make all layout code aware of
the additional features, this patch merely makes the new type available.
|
|
|
|
|
|
|
|
Let's stop putting generic types and AOs from the Web IDL spec into
the Bindings namespace and directory in LibWeb, and instead follow our
usual naming rules of 'directory = namespace = spec name'. The IDL
namespace is already used by LibIDL, so Web::WebIDL seems like a good
choice.
|
|
These are from the HTML spec and therefore belong in the HTML/ directory
in LibWeb. Bindings/ has become a bit of a dumping ground, so this is a
first step towards cleaning that up.
|
