The existing implementation has some pre-existing issues where it is
incorrectly assumes that byte offsets are given through the IDL instead
of UTF-16 code units. While making these changes, leave some FIXMEs for
that.
HTMLTextAreaElement also needs to be told when its contained text node
has been edited, so let's make this functionality work for anyone who
extends the new EditableTextNodeOwner interface class.
Instead of having a nested enum within a struct, use the macro
AK_ENUM_BITWISE_OPERATORS to add all the convienent has_flag free
functions and such for ease of use.
We never implemented this for History::pushState/popState, and now that
we're working on the Navigable changes, we don't need this legacy entry
with its legacy name.
With this change, elements that want to receive viewport rect updates
will need to register on document instead of the browsing context.
This change solves the problem where a browsing context for a document
is guaranteed to exist only while the document is active so browsing
context might not exit by the time DOM node that want to register is
constructed.
This is a part of preparation work before switching to navigables where
this issue becomes more visible.
Using `Core::Timer` that doesn't implicitly convert callback to
`JS::SafeFunction` fixes the bug when `BrowsingContext` is never
destroyed because of cyclic dependency between callback and
`BrowsingContext`.
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
In order to follow spec text to achieve this, we need to change the
underlying representation of a host in AK::URL to deserialized format.
Before this, we were parsing the host and then immediately serializing
it again.
Making that change resulted in a whole bunch of fallout.
After this change, callers can access the serialized data through
this concept-host-serializer. The functional end result of this
change is that IPv6 hosts are now correctly serialized to be
surrounded with '[' and ']'.
BrowsingContext::set_active_document() may end up asking for the Page's
top level browsing context before Page has one. Do a workaround for now
where we have an API to ask if it's initialized.
Long-term we should find a cleaner solution.
This fixes an issue where loading an iframe would cause the current
browser tab title to get overwritten with an empty string.
The problem is that nested browsing contexts can be considered "top
level" during their initialization, but only one browsing context is
ever the Page::top_level_browsing_context(), so that's what we check.
This lets elements figure out if they're visible within the viewport or
not, so they take appropriate action.
Fixes the issues with animations not starting until the viewport was
resized or scrolled.
The "browsing context container" concept in the HTML spec has been
replaced with "navigable container". Renaming this is the first step of
many towards implementing the new world.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
These will need to float around more than they're currently able to.
Put them on the GC heap to prepare for that.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
This now defaults to serializing the path with percent decoded segments
(which is what all callers expect), but has an option not to. This fixes
`file://` URLs with spaces in their paths.
The name has been changed to serialize_path() path to make it more clear
that this method will generate a new string each call (except for the
cannot_be_a_base_url() case). A few callers have then been updated to
avoid repeatedly calling this function.
This ports MouseEvent, UIEvent, WheelEvent, and Event to new String.
They all had a dependency to T::create() in
WebDriverConnection::fire_an_event() and therefore had to be ported in
the same commit.
When scrolling the page, we may need to flush any pending layout
changes. This is required because otherwise, we don't know if the target
scroll position is valid.
However, we don't need to *force* a layout. If the layout tree is
already up-to-date, we can use it as-is.
Also, if we're scrolling to (0, 0), we don't need to update the layout
at all, since (0, 0) is always a guaranteed valid scroll position.
With current process architecture where every top level browsing
context lives in a separate WebContent process we need to request
a browser to spawn new WebContent process if new top level BC is
requested.
The name "initial containing block" was wrong for this, as it doesn't
correspond to the HTML element, and that's specifically what it's
supposed to do! :^)
Because of interdependencies between DOM::Event and UIEvents::MouseEvent
to template function fire_an_event() in WebDriverConnection.cpp, the
commit: 'LibWeb: Make factory methods of UIEvents::MouseEvent fallible'
have been squashed into this commit.
Instead of sifting through the layout tree to extract the selected text,
look at the DOM selection instead.
Note that we can't just stringify the DOM Range, as that would include
non-visible things (like the content of <style> elements, etc.) so we
run it through an ad-hoc variant of the range stringification algorithm.
This can probably be factored better, but it's a start. :^)
...and also for hit testing, which is involved in most of them.
Much of this is temporary conversions and other awkwardness, which
should resolve itself as the rest of LibWeb is converted to these new
types. Hopefully. :thousandyakstare:
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 :^)
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 is the way.
On a more serious note, there's no reason to keep adding ref-counted
classes to LibWeb now that the majority of classes is GC'd - it only
adds the risk of discovering some cycle down the line, and forces us to
use handles as we can't visit().
This removes a set of complex reference cycles between DOM, layout tree
and browsing context.
It also makes lifetimes much easier to reason about, as the DOM and
layout trees are now free to keep each other alive.
(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.
When a new document becomes the active document of a browsing context,
we now notify the old document, allowing it to tear down its layout
tree. In the future, there might be more cleanups we'd like to do here.
With the addition of the 'fetch params' struct, the single ownership
model we had so far falls apart completely.
Additionally, this works nicely for FilteredResponse's internal response
instead of risking a dangling reference.
Replacing the public constructor with a create() function also found a
few instances of a Request being stack-allocated!
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 :^).
URL had properly named replacements for protocol(), set_protocol() and
create_with_file_protocol() already. This patch removes these function
and updates all call sites to use the functions named according to the
specification.
See https://url.spec.whatwg.org/#concept-url-scheme
