Google Docs focuses a "text event target" iframe using Window.focus on
the iframe's contentWindow. Doing so makes the iframe's document the
focused element we have to fire text events at. However, in the top
level browsing context, the focused element is still the iframe, so we
have to repeat the keyboard event steps but with the iframe's nested
browsing context instead.
Since our hit testing mechanism gives you the Paintable under the mouse
cursor, we can't just give up if that paintable doesn't have a
corresponding DOM node. That meant that generated content like pseudo-
elements didn't generate mouse events at all.
Fix this by making a dom_node_for_event_dispatch() helper function that
finds a suitable DOM node when given a paintable. This first cut is very
naive, and there's probably more we should do, but we have to start
somewhere. :^)
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.
This includes punting on the actual file picker implementation all the
way out to the PageClient. It's likely that some of the real details
should be implemented somewhere closer, like the BrowsingContext or the
Page, but we'll get there.
For now, this allows https://copy.sh/v86 to load the emulation of the
preselected images all the way until it hits a call to
URL.createObjectURL.
These classes only needed Window to get at its realm. Pass a realm
directly to construct Crypto, Encoding, HRT, IntersectionObserver,
NavigationTiming, Page, RequestIdleCallback, Selection, Streams, URL,
and XML classes.
This is used by window.close() programmatically, but of course the user
can also decide to close a top-level browsing context at any time by
closing the tab.
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
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.
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.
To achieve this goal:
- The Browser unveils "/tmp/portal/filesystemaccess"
- Pass the page through LoadRequest => ResourceLoader
- ResourceLoader requests a file to the FileSystemAccessServer via IPC
- OutOfProcessWebView handles it and sends a file descriptor back to
the Page.
This improves our spec compliance by allowing the user to click
non-element nodes (like text) and having the click be registered with
the parent element (like a div or button). This makes Fandom's cookie
accept button work if you click the text. Additionally, the events test
page contains a test to check the target element, which would previously
not exist when we fired the event at a non-element.
The WebView url wouldn't update so reload in Tab would still use the
previous URL before any left click navigation.
I am unsure if there was any good reason not to dispatch the event when
there are no modifiers.
This is now the source of truth for 'user enabled/disabled scripting',
but it has to ask the window's page, which actually stores the setting.
Also use this new functionality in two places where it was previously
marked as a FIXME.
This commit moves a couple more special cases in mouse event handling to
handle_mouseup. Additionally, it gets rid of the special casing with
should_dispatch_event and only fires a click event to the EventTarget
when the left mouse button is clicked. Finally it restores the link
context menu callback that was lost during 0fc8c65.
This commit moves the regular handling of links to the anchor elements'
activation behavior, and implements a few auxiliary algorithms as
defined by the HTML specification.
Note that certain things such as javascript links, fragments and opening
a new tab are still handled directly in EventHandler, but they have been
moved to handle_mouseup so that it behaves closer to how it would if it
was entirely up-to-spec.
This is a convenience accessor to avoid having to say this everywhere:
result.paintable->layout_node().dom_node()
Instead, you can now do:
result.dom_node()
This commit is messy due to the Paintable and Layout classes being
tangled together.
The RadioButton, CheckBox and ButtonBox classes are now subclasses of
FormAssociatedLabelableNode. This subclass separates these layout nodes
from LabelableNode, which is also the superclass of non-form associated
labelable nodes (Progress).
ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer
call events on DOM nodes directly from their mouse event handlers;
instead, all the functionality is now directly in EventHandler, which
dispatches the related events. handle_mousedown and related methods
return a bool indicating whether the event handling should proceed.
Paintable classes can now return an alternative DOM::Node which should
be the target of the mouse event. Labels use this to indicate that the
labeled control should be the target of the mouse events.
HTMLInputElement put its activation behavior on run_activation_behavior,
which wasn't actually called anywhere and had to be manually called by
other places. We now use activation_behavior which is used by
EventDispatcher.
This commit also brings HTMLInputElement closer to spec by removing the
did_foo functions that did ad-hoc event dispatching and unifies the
behavior under run_input_activation_behavior.
Everything related to hit testing is better off using the painting tree.
The thing being mousemoved over is a paintable, so let's hand that out
directly instead of the corresponding layout node.
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
Make sure to refresh the contents of text-<input> when pressing
backspace or delete key.
The methods 'handle_insert()' and 'handle_delete()' already had the call
to 'm_browsing_context.active_document()->force_layout()' so let us also
add it to 'handle_delete_character_after()'.
If the mousedown event hits something with is_focusable()==true,
we now update the document's focused element *instead* of placing the
text cursor at the focusable element.
This allows you to begin editing input elements by clicking them.
This feels very hackish and we'll need to come up with something nicer.
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
Instead of doing layout synchronously whenever something changes,
we now use a basic event loop timer to defer and coalesce relayouts.
If you did something that requires a relayout of the page, make sure
to call Document::set_needs_layout() and it will get coalesced with all
the other layout updates.
There's lots of room for improvement here, but this already makes many
web pages significantly snappier. :^)
Also, note that this exposes a number of layout bugs where we have been
relying on multiple relayouts to calculate the correct dimensions for
things. Now that we only do a single layout in many cases, these kind of
problems are much more noticeable. That should also make them easier to
figure out and fix. :^)
This patch adds the "has a rendering opportunity" concept from the spec
to BrowsingContext and uses it to filter out contexts that are unable
to render right now when doing the event loop's rendering updates.
Note that we actually consider all contexts to have a rendering
opportunity at all times right now. Coming up with reasons to avoid
rendering is left as a FIXME. :^)
This namespace will be used for all interfaces defined in the URL
specification, like URL and URLSearchParams.
This has the unfortunate side-effect of requiring us to use the fully
qualified AK::URL name whenever we want to refer to the AK class, so
this commit also fixes all such references.
This is in preparation for implementing JS scrolling functions, which
specify both x and y scrolling deltas. The visible behavior has not
changed.
Also, moved the "mouse wheel delta * 20" calculation to the
`EventHandler` since the JS calls will want to work directly in pixels.
Any browsing context that doesn't have a parent browsing context is now
considered a top-level browsing context. This matches the HTML spec.
This means we no longer keep a pointer to the top-level context, since
we can simply walk the parent chain until we find the topmost ancestor.
We already have a base class for frame elements that we call
BrowsingContextContainer. This patch makes BrowsingContext::container()
actually return one of those.
This makes us match the spec names, and also solves a FIXME about having
a shared base for <frame> and <iframe>. (We already had the shared base,
but the pointer we had there wasn't tightly typed enough.)
At the moment, nested browsing contexts expect that there's always a
top-level browsing context at some higher level. That's okay, but let's
keep the top-level pointer in a WeakPtr to make it easier to catch
mistakes (as this turns UAF into a null dereference.)
If the text-for-rendering of the last selected node is empty, the select
all implementation would end up setting the index to -1. This value is
used directly for a substring length in the copy text implementation,
thus would cause a failed assertion.
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.
The previous behavior was to always VERIFY that the UTF-8 bytes were
valid when iterating over the code points of an UTF8View. This change
makes it so we instead output the 0xFFFD 'REPLACEMENT CHARACTER'
code point when encountering invalid bytes, and keep iterating the
view after skipping one byte.
Leaving the decision to the consumer would break symmetry with the
UTF32View API, which would in turn require heavy refactoring and/or
code duplication in generic code such as the one found in
Gfx::Painter and the Shell.
To make it easier for the consumers to detect the original bytes, we
provide a new method on the iterator that returns a Span over the
data that has been decoded. This method is immediately used in the
TextNode::compute_text_for_rendering method, which previously did
this in a ad-hoc waay.
This also add tests for the new behavior in TestUtf8.cpp, as well
as reinforcements to the existing tests to check if the underlying
bytes match up with their expected values.
Our "frame" concept very closely matches what the web specs call a
"browsing context", so let's rename it to that. :^)
The "main frame" becomes the "top-level browsing context",
and "sub-frames" are now "nested browsing contexts".
This patch updates the Page::keydown_event event handler to implement
crude Unicode support. It implements new method in EditEventHandler to
more easily handle deleting a single character after the cursor.
Furthermore, it makes use of the previously implemented methods to
increment and decrement the cursor position, which take into account
that Unicode codepoint may be multiple bytes wide.
This means it is now possible to mostly edit Unicode in editable DOM
nodes without any crashes. :^)
This introduces methods to increment and decrement the cursor position.
This is non-trivial as the cursor position is specified in bytes rather
than codepoints. Thus, it sometimes needs to be incremented or
decremented by more than one, depending on the codepoint to "jump over".
Because the cursor blink cycle needs to be reset after moving the
cursor, methods calling the ones in DOM::Position are implemented in
Frame. Furthermore, this allows the cursor_position() getter to stay
const. :^)
Additionally, it adds a offset_is_at_end_of_node() method which checks
if the current offset points to the end of the node.
This patch makes two modifications to improve the behavior of cursors in
editable DOM nodes, such as HTML tags with the contenteditable
attribute.
When the cursor blink cycle is reset in an editable DOM node, a repaint
should be initiated. For this, set_needs_display() needs to be called on
the layout node. Previously, the cursor blink cycle would not reset
properly and moving the cursor with the arrow keys did not feel
intuitive.
Furthermore, this modifies one of the conditions necessary to actually
paint the cursor, which previously prevented it from being painted when
at the end of a text node, after all the text present.
Before this patch, pressing modifier keys such as Ctrl would insert
whitespace into editable DOM nodes. This patch crudely fixes that
behavior by checking if the codepoint associated with the event is
non-zero.
This patch downgrades some TODO() calls when the cursor in an editable
DOM node should move to the previous or next node. Previously, the
process would crash, whereas now, the cursor will just stay where it
was.
This seems more sensible for now, as there is no reason to crash just
because of this.
A Frame now knows about its nesting-level.
The FrameLoader checks whether the recursion level of the current
frame allows it to be displayed and if not doesn't even load the
requested resource.
The nesting-check is done on a per-URL-basis, so there can be many many
nested Frames as long as they have different URLs.
If there are however Frames with the same URL nested inside each other
we only allow this to happen 3 times.
This mitigates infinetely recursing <iframe>s in an HTML-document
crashing the browser with an OOM.
This commit unifies methods and method/param names between the above
classes, as well as adds [[nodiscard]] and ALWAYS_INLINE where
appropriate. It also renamed the various move_by methods to
translate_by, as that more closely matches the transformation
terminology.
HTMLCollection is an awkward legacy interface from the DOM spec.
It provides a live view of a DOM subtree, with some kind of filtering
that determines which elements are part of the collection.
We now return HTMLCollection objects from these APIs:
- getElementsByClassName()
- getElementsByName()
- getElementsByTagName()
This initial implementation does not do any kind of caching, since that
is quite a tricky problem, and there will be plenty of time for tricky
problems later on when the engine is more mature.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
To protect the main Browser process against nefarious cookies, parse the
cookies out-of-process and then send the parsed result over IPC to the
main process. This way, if the cookie parser blows up, only that tab
will be affected.
This flag warns on classes which have `virtual` functions but do not
have a `virtual` destructor.
This patch adds both the flag and missing destructors. The access level
of the destructors was determined by a two rules of thumb:
1. A destructor should have a similar or lower access level to that of a
constructor.
2. Having a `private` destructor implicitly deletes the default
constructor, which is probably undesirable for "interface" types
(classes with only virtual functions and no data).
In short, most of the added destructors are `protected`, unless the
compiler complained about access.
These provide the cursor coordinate within the viewport at which the
event occurred (as opposed to the page relative coordinates exposed via
offsetX, offsetY).
To implement the HttpOnly attribute, the CookieJar needs to know where a
request originated from. Namely, it needs to distinguish between HTTP /
non-HTTP (i.e. JavaScript) requests. When the HttpOnly attribute is set,
requests from JavaScript are to be blocked.
The mutation algorithms now more closely follow the spec and
fixes some assertion failures in tests such as Acid3 and Dromaeo.
The main thing that is missing right now is passing exceptions to the
bindings layer. This is because of issue #6075. I spent a while trying
to work it out and got so frustrated I just left it as a FIXME. Besides
that, the algorithms bail at the appropriate points.
This also makes the adopting steps in the document more spec compliant
as it's needed by the insertion algorithm. While I was at it, I added
the adoptNode IDL binding.
This adds a bunch of ancestor/descendant checks to TreeNode as well.
I moved the "remove_all_children" function to Node as it needs to use
the full remove algorithm instead of simply removing it from
the child list.
It's a little awkward that we do this in two places, but IPWV and OOPWV
currently implement resizing a little differently from each other so we
need to cover both paths.
When a mousewheel scroll event isn't handled by the web content
itself (e.g. an overflowed box or similar), the event needs to get
passed back up to the OutOfProcessWebView.
We try scrolling a Node with the handle_mousewheel event, but if it
isn't scrollable, the event should be passed back up to the page
host. This is the first step in that process.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
This is rather crude, but you can now use the mouse wheel to scroll up
and down in block-level boxes with clipped overflowing content.
There's no limit to how far you can scroll in either direction, since
we don't yet track how much overflow there is. But it's a start. :^)
The approach of attaching sub-widgets to the web view widget was only
ever going to work in single-process mode, and that's not what we're
about anymore, so let's just get rid of WidgetBox so we don't have the
dead-end architecture hanging over us.
The next step here is to re-implement <input type=text> using LibWeb
primitives.
We'll want to remove the LibGUI dependency from the WebContent process.
This is the first basic step of removing unnecessary LibGUI includes
and swapping out GUI::Painter for Gfx::Painter.
The WebContent process was redoing page layout every time you scrolled
the page. This was a huge CPU hog for no reason. Fix this by only doing
a relayout when the viewport is resized, not when it moves around.
Also stop exposing the DOM cursor as a mutable reference on Frame,
since event handling code was using that to mess with the text offset
directly. Setting the cursor now always goes through the Frame where
we can reset the blink cycle appropriately.
This makes cursor movement look a lot more natural. :^)
This is a workaround until we can implement a proper <input type=text>
in terms of LibWeb primitives.
This makes google.com not crash in multi-process mode (but there is no
search box.)
Image boxes want to know whether they are inside the visible viewport.
This is used to pause/resume animations, and to update the purgeable
memory volatility state.
Previously we would traverse the entire layout tree on every resize,
calling a helper on each ImageBox. Make those boxes register with the
frame they are interested in instead, saving us all that traversal.
This also makes it easier for other parts of the code to learn about
viewport changes in the future. :^)
A C++ source file containing just
#include <LibFoo/Bar.h>
should always compile cleanly.
This patch adds missing header inclusions that could have caused weird error
messages if they were used in a different context. Also, this confused QtCreator.
