Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Page/EventHandler.cpp

1404 lines
68 KiB
C++
Raw Normal View History

LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020-2021, Andreas Kling <andreas@ladybird.org>
LibWeb: Do nothing when pressing modifier keys in HTML contenteditable 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.
2021-05-18 13:13:58 +02:00
* Copyright (c) 2021, Max Wipfli <mail@maxwipfli.ch>
LibGfx+LibWeb: Cache SkImage in ImmutableBitmap By caching the SkImage that is reused across repaints, we allow Skia t optimize GPU texture caching. ImmutableBitmap is chosen to own the SkImage because it guarantees that the underlying pixels cannot be modified. This is not the case for Gfx::Bitmap, where invalidating the SkImage would be challenging since it exposes pointers to underlying data through methods like scanline().
2024-11-09 05:48:17 +01:00
* Copyright (c) 2024, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
*
Everything: Move to SPDX license identifiers in all files. 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 *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
*/
LibWeb: Only fire keypress events if the key press produced a character For example, pressing just the shift key should not producde a keypress event.
2024-10-08 17:15:55 -04:00
#include <LibUnicode/CharacterTypes.h>
LibWeb: Use a Unicode text segmenter to select words on double-click We currently use a naive word segmentation, looking for ASCII spaces to mark a word boundary. Use LibUnicode's complete implementation instead.
2024-08-27 08:19:03 -04:00
#include <LibUnicode/Segmenter.h>
LibWeb: Allow inserting text at the cursor by typing characters :^) This works everywhere right now, but it's obviously not going to stay that way forever. :^) Note that this does not advance the cursor correctly for whitespace since the cursor is DOM-based and doesn't take whitespace collapsing into account yet.
2020-08-02 12:10:01 +02:00
#include <LibWeb/DOM/Text.h>
LibWeb: Implement CloseWatcher API This implements most of the CloseWatcher API from the html spec. AbortSignal support is unimplemented. Integration with dialogs and popovers is also unimplemented.
2024-06-21 22:53:05 +01:00
#include <LibWeb/HTML/CloseWatcherManager.h>
LibWeb: Use the focus steps instead of set_focused_element on user click This makes clicking properly fire focus/blur events alongside setting the focused element.
2022-11-05 14:34:24 +00:00
#include <LibWeb/HTML/Focus.h>
LibWeb: Move MouseEvent into the UIEvents namespace Named after the UIEvents specification that houses MouseEvent.
2020-07-28 17:21:23 +02:00
#include <LibWeb/HTML/HTMLAnchorElement.h>
LibWeb: Implement implicit submission of HTMLFormElement
2024-01-31 13:26:01 -05:00
#include <LibWeb/HTML/HTMLFormElement.h>
LibWeb: Move MouseEvent into the UIEvents namespace Named after the UIEvents specification that houses MouseEvent.
2020-07-28 17:21:23 +02:00
#include <LibWeb/HTML/HTMLIFrameElement.h>
LibWeb: Add a PageClient callback for image context menu requests When the user right-clicks on an image, you might want to show a special context menu, separate from the regular link context menu. This patch only implements enough of the functionality to get this working in a single-process context.
2020-10-02 19:01:51 +02:00
#include <LibWeb/HTML/HTMLImageElement.h>
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
#include <LibWeb/HTML/HTMLMediaElement.h>
Browser+LibWeb+WebContent: Broadcast video element context menu requests This just sets up the IPC to notify the browser process of context menu requests on video elements. The IPC contains a few pieces of information about the state of the video element.
2023-05-15 09:42:56 -04:00
#include <LibWeb/HTML/HTMLVideoElement.h>
LibWeb: Dispatch "click" event on input control associated with <label> For example, in the following HTML: ```html <label> <input type="radio" name="fruit" value="apple" id="radio1"> <span class="box"></span> </label> ``` When any descendant of a <label> element is clicked, a "click" event must be dispatched on the <input> element nested within the <label>, in addition to the "click" event dispatched on the clicked descendant. Previously, this behavior was implemented only for text node descendants by "overriding" the mouse event target using `mouse_event_target()` in the TextPaintable. This approach was incorrect because it was limited to text nodes, whereas the behavior should apply to any box. Moreover, the "click" event for the input control must be dispatched *in addition* to the event on the clicked element, rather than redirecting it.
2024-11-20 21:31:13 +01:00
#include <LibWeb/Layout/Label.h>
LibWeb: Rename Layout::InitialContainingBlock to Layout::Viewport 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! :^)
2023-02-25 11:04:29 +01:00
#include <LibWeb/Layout/Viewport.h>
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
#include <LibWeb/Page/DragAndDropEventHandler.h>
LibWeb: Move the Page/Frame/EventHandler classes into Page/
2020-07-28 19:27:41 +02:00
#include <LibWeb/Page/EventHandler.h>
LibWeb+Browser: Remove unnecessary InProcessWebView.h includes
2021-08-24 16:28:08 +02:00
#include <LibWeb/Page/Page.h>
LibWeb: Move PaintingBox to its own .cpp and .h files
2022-03-10 23:13:37 +01:00
#include <LibWeb/Painting/PaintableBox.h>
LibWeb: Store "text for rendering" in TextPaintable Instead of TextPaintable fragments being an offset+length view into the layout node, they are now a view into the paintable instead. This removes an awkward time window where we'd have bogus state in text fragments after layout invalidation but before relayout. It also makes the code slightly nicer in general, since there's less mixing of layout and painting concepts.
2024-03-18 10:25:57 +01:00
#include <LibWeb/Painting/TextPaintable.h>
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
#include <LibWeb/Selection/Selection.h>
LibWeb: Add HTML::EventNames and UIEvents::EventNames
2020-11-21 19:15:57 +00:00
#include <LibWeb/UIEvents/EventNames.h>
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
#include <LibWeb/UIEvents/InputEvent.h>
#include <LibWeb/UIEvents/InputTypes.h>
LibWeb: Add a basic KeyboardEvent and fire "keydown" events :^)
2021-09-27 23:22:21 +02:00
#include <LibWeb/UIEvents/KeyboardEvent.h>
LibWeb: Add Web::UIEvents::MouseButton enum, drop dependency on LibGUI This was the only thing LibWeb needed from LibGUI, and we can just duplicate the enum in LibWeb and get rid of a bogus dependency.
2024-06-02 19:00:42 +02:00
#include <LibWeb/UIEvents/MouseButton.h>
LibWeb: Move MouseEvent into the UIEvents namespace Named after the UIEvents specification that houses MouseEvent.
2020-07-28 17:21:23 +02:00
#include <LibWeb/UIEvents/MouseEvent.h>
LibWeb: Dispatch pointer events in EventHandler Now, along with the mouse events we also dispatch pointerup, pointerdown and pointermove. With this change shape painting works on https://excalidraw.com/
2024-11-21 21:35:49 +01:00
#include <LibWeb/UIEvents/PointerEvent.h>
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
#include <LibWeb/UIEvents/WheelEvent.h>
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
namespace Web {
LibWeb: Fix "input" events being dispatched twice when cancelled
2024-10-22 23:09:27 +02:00
#define FIRE(expression) \
if (auto event_result = (expression); event_result == EventResult::Cancelled) \
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
return event_result;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
static GC::Ptr<DOM::Node> dom_node_for_event_dispatch(Painting::Paintable& paintable)
LibWeb: Try harder to find a suitable DOM node for mouse event dispatch 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. :^)
2022-10-23 17:53:02 +02:00
{
if (auto node = paintable.dom_node())
return node;
LibWeb: Fix hit-testing for button element Change 'dom_node_for_event_dispatch' to locate the closest layout node with a DOM node instead of only checking the direct ancestor. This fixes hit-testing for buttons because they are wrapped into multiple anonymous layout nodes (internally we use flex formatting for them).
2024-02-12 14:58:10 +01:00
auto* layout_parent = paintable.layout_node().parent();
while (layout_parent) {
if (auto* node = layout_parent->dom_node())
return node;
layout_parent = layout_parent->parent();
}
LibWeb: Try harder to find a suitable DOM node for mouse event dispatch 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. :^)
2022-10-23 17:53:02 +02:00
return nullptr;
}
LibWeb: Dispatch "click" event on input control associated with <label> For example, in the following HTML: ```html <label> <input type="radio" name="fruit" value="apple" id="radio1"> <span class="box"></span> </label> ``` When any descendant of a <label> element is clicked, a "click" event must be dispatched on the <input> element nested within the <label>, in addition to the "click" event dispatched on the clicked descendant. Previously, this behavior was implemented only for text node descendants by "overriding" the mouse event target using `mouse_event_target()` in the TextPaintable. This approach was incorrect because it was limited to text nodes, whereas the behavior should apply to any box. Moreover, the "click" event for the input control must be dispatched *in addition* to the event on the clicked element, rather than redirecting it.
2024-11-20 21:31:13 +01:00
static DOM::Node* input_control_associated_with_ancestor_label_element(Painting::Paintable& paintable)
{
if (is<Layout::Label>(paintable.layout_node())) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto const& label = as<Layout::Label>(paintable.layout_node());
LibWeb: Dispatch "click" event on input control associated with <label> For example, in the following HTML: ```html <label> <input type="radio" name="fruit" value="apple" id="radio1"> <span class="box"></span> </label> ``` When any descendant of a <label> element is clicked, a "click" event must be dispatched on the <input> element nested within the <label>, in addition to the "click" event dispatched on the clicked descendant. Previously, this behavior was implemented only for text node descendants by "overriding" the mouse event target using `mouse_event_target()` in the TextPaintable. This approach was incorrect because it was limited to text nodes, whereas the behavior should apply to any box. Moreover, the "click" event for the input control must be dispatched *in addition* to the event on the clicked element, rather than redirecting it.
2024-11-20 21:31:13 +01:00
return label.dom_node().control().ptr();
}
if (auto const* label = paintable.layout_node().first_ancestor_of_type<Layout::Label>())
return label->dom_node().control().ptr();
return nullptr;
}
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
static bool parent_element_for_event_dispatch(Painting::Paintable& paintable, GC::Ptr<DOM::Node>& node, Layout::Node*& layout_node)
LibWeb: Move code for finding the parent element into a helper function This exact same loop is repeated a couple of times.
2022-10-24 03:24:19 +02:00
{
LibWeb: Don't dispatch click events to disabled FormAssociatedElements Disabled FormAssociatedElements also no longer receive focus when clicked.
2024-07-12 11:06:08 +01:00
auto* current_ancestor_node = node.ptr();
do {
if (is<HTML::FormAssociatedElement>(current_ancestor_node) && !dynamic_cast<HTML::FormAssociatedElement*>(current_ancestor_node)->enabled()) {
return false;
}
} while ((current_ancestor_node = current_ancestor_node->parent()));
LibWeb: Move code for finding the parent element into a helper function This exact same loop is repeated a couple of times.
2022-10-24 03:24:19 +02:00
layout_node = &paintable.layout_node();
while (layout_node && node && !node->is_element() && layout_node->parent()) {
layout_node = layout_node->parent();
LibWeb: Skip anonymous layout nodes while finding the event target This makes the links on nitter.net clickable, e.g. "preferences" in the upper right corner.
2022-11-06 21:45:30 +01:00
if (layout_node->is_anonymous())
continue;
LibWeb: Move code for finding the parent element into a helper function This exact same loop is repeated a couple of times.
2022-10-24 03:24:19 +02:00
node = layout_node->dom_node();
}
return node && layout_node;
}
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
static Gfx::Cursor resolve_cursor(Layout::NodeWithStyle const& layout_node, Vector<CSS::CursorData> const& cursor_data, Gfx::StandardCursor auto_cursor)
LibWeb: Call `page_did_request_cursor_change` with CSS cursor
2021-02-21 20:15:00 +00:00
{
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
for (auto const& cursor : cursor_data) {
auto result = cursor.visit(
[auto_cursor](CSS::Cursor css_cursor) -> Optional<Gfx::Cursor> {
switch (css_cursor) {
case CSS::Cursor::Crosshair:
case CSS::Cursor::Cell:
return Gfx::StandardCursor::Crosshair;
case CSS::Cursor::Grab:
case CSS::Cursor::Grabbing:
return Gfx::StandardCursor::Drag;
case CSS::Cursor::Pointer:
return Gfx::StandardCursor::Hand;
case CSS::Cursor::Help:
return Gfx::StandardCursor::Help;
case CSS::Cursor::None:
return Gfx::StandardCursor::Hidden;
case CSS::Cursor::NotAllowed:
return Gfx::StandardCursor::Disallowed;
case CSS::Cursor::Text:
case CSS::Cursor::VerticalText:
return Gfx::StandardCursor::IBeam;
case CSS::Cursor::Move:
case CSS::Cursor::AllScroll:
return Gfx::StandardCursor::Move;
case CSS::Cursor::Progress:
case CSS::Cursor::Wait:
return Gfx::StandardCursor::Wait;
case CSS::Cursor::ColResize:
return Gfx::StandardCursor::ResizeColumn;
case CSS::Cursor::EResize:
case CSS::Cursor::WResize:
case CSS::Cursor::EwResize:
return Gfx::StandardCursor::ResizeHorizontal;
case CSS::Cursor::RowResize:
return Gfx::StandardCursor::ResizeRow;
case CSS::Cursor::NResize:
case CSS::Cursor::SResize:
case CSS::Cursor::NsResize:
return Gfx::StandardCursor::ResizeVertical;
case CSS::Cursor::NeResize:
case CSS::Cursor::SwResize:
case CSS::Cursor::NeswResize:
return Gfx::StandardCursor::ResizeDiagonalBLTR;
case CSS::Cursor::NwResize:
case CSS::Cursor::SeResize:
case CSS::Cursor::NwseResize:
return Gfx::StandardCursor::ResizeDiagonalTLBR;
case CSS::Cursor::ZoomIn:
case CSS::Cursor::ZoomOut:
return Gfx::StandardCursor::Zoom;
case CSS::Cursor::Auto:
return auto_cursor;
case CSS::Cursor::ContextMenu:
case CSS::Cursor::Alias:
case CSS::Cursor::Copy:
case CSS::Cursor::NoDrop:
// FIXME: No corresponding GFX Standard Cursor, fallthrough to None
case CSS::Cursor::Default:
default:
return Gfx::StandardCursor::None;
}
},
[&layout_node](NonnullRefPtr<CSS::CursorStyleValue> const& cursor_style_value) -> Optional<Gfx::Cursor> {
if (auto image_cursor = cursor_style_value->make_image_cursor(layout_node); image_cursor.has_value())
return image_cursor.release_value();
return {};
});
if (result.has_value())
return result.release_value();
LibWeb: Call `page_did_request_cursor_change` with CSS cursor
2021-02-21 20:15:00 +00:00
}
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
// We should never get here
return Gfx::StandardCursor::None;
LibWeb: Call `page_did_request_cursor_change` with CSS cursor
2021-02-21 20:15:00 +00:00
}
LibWeb: Make MouseEvent.offsetX/Y ignore transforms That is what the spec calls it, at least. In code, this manifests as making the offset very aware of the element's transform, because the click position comes relative to the viewport, not to the transformed element.
2024-11-19 22:26:00 +01:00
// https://drafts.csswg.org/cssom-view/#dom-mouseevent-offsetx
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
static CSSPixelPoint compute_mouse_event_offset(CSSPixelPoint position, Painting::Paintable const& paintable)
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
{
LibWeb: Make MouseEvent.offsetX/Y ignore transforms That is what the spec calls it, at least. In code, this manifests as making the offset very aware of the element's transform, because the click position comes relative to the viewport, not to the transformed element.
2024-11-19 22:26:00 +01:00
// If the event’s dispatch flag is set,
// FIXME: Is this guaranteed to be dispatched?
// return the x-coordinate of the position where the event occurred,
Gfx::Point<float> precision_offset = {
position.x().to_double(),
position.y().to_double()
};
// ignoring the transforms that apply to the element and its ancestors,
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
if (paintable.layout_node().has_css_transform()) {
auto const& paintable_box = static_cast<Painting::PaintableBox const&>(paintable);
auto const affine_transform = Gfx::extract_2d_affine_transform(paintable_box.transform().inverse());
LibWeb: Make MouseEvent.offsetX/Y ignore transforms That is what the spec calls it, at least. In code, this manifests as making the offset very aware of the element's transform, because the click position comes relative to the viewport, not to the transformed element.
2024-11-19 22:26:00 +01:00
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto const& origin = paintable_box.transform_origin();
LibWeb: Make MouseEvent.offsetX/Y ignore transforms That is what the spec calls it, at least. In code, this manifests as making the offset very aware of the element's transform, because the click position comes relative to the viewport, not to the transformed element.
2024-11-19 22:26:00 +01:00
Gfx::Point<float> const precision_origin = {
origin.x().to_double(),
origin.y().to_double()
};
precision_offset.translate_by(-precision_origin);
precision_offset.transform_by(affine_transform);
precision_offset.translate_by(precision_origin);
}
// relative to the origin of the padding edge of the target node
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto const top_left_of_layout_node = paintable.box_type_agnostic_position();
LibWeb: Make MouseEvent.offsetX/Y ignore transforms That is what the spec calls it, at least. In code, this manifests as making the offset very aware of the element's transform, because the click position comes relative to the viewport, not to the transformed element.
2024-11-19 22:26:00 +01:00
CSSPixelPoint offset = {
CSSPixels(precision_offset.x()),
CSSPixels(precision_offset.y())
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
};
LibWeb: Make MouseEvent.offsetX/Y ignore transforms That is what the spec calls it, at least. In code, this manifests as making the offset very aware of the element's transform, because the click position comes relative to the viewport, not to the transformed element.
2024-11-19 22:26:00 +01:00
offset -= top_left_of_layout_node;
// and terminate these steps.
return offset;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb: Implement user-select This implements all values of user-select.
2025-01-08 01:51:29 +01:00
// https://drafts.csswg.org/css-ui/#propdef-user-select
static void set_user_selection(GC::Ptr<DOM::Node> anchor_node, unsigned anchor_offset, GC::Ptr<DOM::Node> focus_node, unsigned focus_offset, Selection::Selection* selection, CSS::UserSelect user_select)
{
// https://drafts.csswg.org/css-ui/#valdef-user-select-contain
// NOTE: This is clamping the focus node to any node with user-select: contain that stands between it and the anchor node.
if (focus_node != anchor_node) {
// UAs must not allow a selection which is started in this element to be extended outside of this element.
auto potential_contain_node = anchor_node;
// NOTE: The way we do this is searching up the tree from the anchor, to find 'this element', i.e. its nearest contain ancestor.
// We stop the search early when we reach an element that contains both the anchor and the focus node, as this means they
// are inside the same contain element, or not in a contain element at all.
// This takes care of the "selection trying to escape from a contain" case.
while (
(!potential_contain_node->is_element() || potential_contain_node->layout_node()->user_select_used_value() != CSS::UserSelect::Contain) && potential_contain_node->parent() && !potential_contain_node->is_inclusive_ancestor_of(*focus_node)) {
potential_contain_node = potential_contain_node->parent();
}
if (
potential_contain_node->layout_node()->user_select_used_value() == CSS::UserSelect::Contain && !potential_contain_node->is_inclusive_ancestor_of(*focus_node)) {
if (focus_node->is_before(*potential_contain_node)) {
focus_offset = 0;
} else {
focus_offset = potential_contain_node->length();
}
focus_node = potential_contain_node;
// NOTE: Prevents this from being handled again further down
user_select = CSS::UserSelect::Contain;
} else {
// A selection started outside of this element must not end in this element. If the user attempts to create such a
// selection, the UA must instead end the selection range at the element boundary.
// NOTE: This branch takes care of the "selection trying to intrude into a contain" case.
// This is done by searching up the tree from the focus node, to see if there is a
// contain element between it and the common ancestor that also includes the anchor.
// We stop once reaching target_node, which is the common ancestor identified in step 1.
// If target_node wasn't a common ancestor, we would not be here.
auto target_node = potential_contain_node;
potential_contain_node = focus_node;
while (
(!potential_contain_node->is_element() || potential_contain_node->layout_node()->user_select_used_value() != CSS::UserSelect::Contain) && potential_contain_node->parent() && potential_contain_node != target_node) {
potential_contain_node = potential_contain_node->parent();
}
if (
potential_contain_node->layout_node()->user_select_used_value() == CSS::UserSelect::Contain && !potential_contain_node->is_inclusive_ancestor_of(*anchor_node)) {
if (potential_contain_node->is_before(*anchor_node)) {
focus_node = potential_contain_node->next_in_pre_order();
while (potential_contain_node->is_inclusive_ancestor_of(*focus_node)) {
focus_node = focus_node->next_in_pre_order();
}
focus_offset = 0;
} else {
focus_node = potential_contain_node->previous_in_pre_order();
while (potential_contain_node->is_inclusive_ancestor_of(*focus_node)) {
focus_node = focus_node->previous_in_pre_order();
}
focus_offset = focus_node->length();
}
// NOTE: Prevents this from being handled again further down
user_select = CSS::UserSelect::Contain;
}
}
}
switch (user_select) {
case CSS::UserSelect::None:
// https://drafts.csswg.org/css-ui/#valdef-user-select-none
// The UA must not allow selections to be started in this element.
if (anchor_node == focus_node) {
return;
}
// A selection started outside of this element must not end in this element. If the user attempts to create such a
// selection, the UA must instead end the selection range at the element boundary.
while (focus_node->parent() && focus_node->parent()->layout_node()->user_select_used_value() == CSS::UserSelect::None) {
focus_node = focus_node->parent();
}
if (focus_node->is_before(*anchor_node)) {
auto none_element = focus_node;
do {
focus_node = focus_node->next_in_pre_order();
} while (none_element->is_inclusive_ancestor_of(*focus_node));
focus_offset = 0;
} else {
focus_node = focus_node->previous_in_pre_order();
focus_offset = focus_node->length();
}
break;
case CSS::UserSelect::All:
// https://drafts.csswg.org/css-ui/#valdef-user-select-all
// The content of the element must be selected atomically: If a selection would contain part of the element,
// then the selection must contain the entire element including all its descendants. If the element is selected
// and the used value of 'user-select' on its parent is 'all', then the parent must be included in the selection,
// recursively.
while (focus_node->parent() && focus_node->parent()->layout_node()->user_select_used_value() == CSS::UserSelect::All) {
if (anchor_node == focus_node) {
anchor_node = focus_node->parent();
}
focus_node = focus_node->parent();
}
if (focus_node == anchor_node) {
if (anchor_offset > focus_offset) {
anchor_offset = focus_node->length();
focus_offset = 0;
} else {
anchor_offset = 0;
focus_offset = focus_node->length();
}
} else if (focus_node->is_before(*anchor_node)) {
focus_offset = 0;
} else {
focus_offset = focus_node->length();
}
break;
case CSS::UserSelect::Contain:
// NOTE: This is handled at the start of this function
break;
case CSS::UserSelect::Text:
// https://drafts.csswg.org/css-ui/#valdef-user-select-text
// The element imposes no constraint on the selection.
break;
case CSS::UserSelect::Auto:
VERIFY_NOT_REACHED();
break;
}
(void)selection->set_base_and_extent(*anchor_node, anchor_offset, *focus_node, focus_offset);
}
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
EventHandler::EventHandler(Badge<HTML::Navigable>, HTML::Navigable& navigable)
: m_navigable(navigable)
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
, m_drag_and_drop_event_handler(make<DragAndDropEventHandler>())
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
{
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
EventHandler::~EventHandler() = default;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
Painting::PaintableBox* EventHandler::paint_root()
{
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
return nullptr;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
return m_navigable->active_document()->paintable_box();
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
}
Painting::PaintableBox const* EventHandler::paint_root() const
{
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
return nullptr;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
return m_navigable->active_document()->paintable_box();
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
EventResult EventHandler::handle_mousewheel(CSSPixelPoint viewport_position, CSSPixelPoint screen_position, u32 button, u32 buttons, u32 modifiers, int wheel_delta_x, int wheel_delta_y)
LibWeb: Plumb wheel events from widget layer to EventHandler
2021-02-22 19:45:41 +01:00
{
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (should_ignore_device_input_event())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->active_document()->update_layout();
LibWeb: Flush any pending layout updates before processing mouse events We want to make sure the layout and paint trees are up-to-date before handling any mouse events.
2022-03-16 18:50:56 +01:00
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
if (!paint_root())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Allow scrolling overflowed content with the mouse wheel :^) 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. :^)
2021-02-22 19:48:24 +01:00
LibWeb: Add Web::UIEvents::KeyCode and KeyModifier enums, drop Kernel This was the last Kernel header we had. Move the definitions we need into a UIEvents header similar to MouseButton.
2024-06-06 13:29:08 -06:00
if (modifiers & UIEvents::KeyModifier::Mod_Shift)
WebContent: Switch scroll direction on shift modifier
2022-01-20 22:35:01 +01:00
swap(wheel_delta_x, wheel_delta_y);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
auto handled_event = EventResult::Dropped;
LibWeb: Allow scrolling overflowed content with the mouse wheel :^) 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. :^)
2021-02-22 19:48:24 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Painting::Paintable> paintable;
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = target_for_mouse_position(viewport_position); result.has_value())
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
paintable = result->paintable;
LibWeb: Handle scrolling an OutOfProcessWebView 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.
2021-03-02 08:39:07 +11:00
LibWeb: Check paintable of target against null in mousewheel handling
2023-08-09 22:36:46 +00:00
if (paintable) {
auto* containing_block = paintable->containing_block();
while (containing_block) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto handled_scroll_event = containing_block->handle_mousewheel({}, viewport_position, buttons, modifiers, wheel_delta_x, wheel_delta_y);
LibWeb: Skip page scrolling for wheel events consumed by scrollable box Fixes the bug when we scroll both scrollable box and page.
2024-02-29 10:35:25 +01:00
if (handled_scroll_event)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Check paintable of target against null in mousewheel handling
2023-08-09 22:36:46 +00:00
containing_block = containing_block->containing_block();
LibWeb: Find closest scrollable paintable to call handle_mousewheel() This makes event handler to try to find scrollable paintable in the chain of containing blocks of hit box. This is very naive and will have to be improved in the future.
2023-08-06 14:36:02 +02:00
}
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (paintable->handle_mousewheel({}, viewport_position, buttons, modifiers, wheel_delta_x, wheel_delta_y))
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
LibWeb: Try harder to find a suitable DOM node for mouse event dispatch 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. :^)
2022-10-23 17:53:02 +02:00
auto node = dom_node_for_event_dispatch(*paintable);
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
if (node) {
// FIXME: Support wheel events in nested browsing contexts.
if (is<HTML::HTMLIFrameElement>(*node)) {
LibWeb: Redirect wheel events to iframe if needed in EventHandler
2024-02-03 11:01:31 +01:00
auto& iframe = static_cast<HTML::HTMLIFrameElement&>(*node);
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto position_in_iframe = viewport_position.translated(compute_mouse_event_offset({}, *paintable));
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
iframe.content_navigable()->event_handler().handle_mousewheel(position_in_iframe, screen_position, button, buttons, modifiers, wheel_delta_x, wheel_delta_y);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
}
// Search for the first parent of the hit target that's an element.
LibWeb: Fix a few const-ness issues
2023-02-25 10:44:51 -07:00
Layout::Node* layout_node;
LibWeb: Move code for finding the parent element into a helper function This exact same loop is repeated a couple of times.
2022-10-24 03:24:19 +02:00
if (!parent_element_for_event_dispatch(*paintable, node, layout_node))
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto page_offset = compute_mouse_event_page_offset(viewport_position);
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto offset = compute_mouse_event_offset(page_offset, *layout_node->first_paintable());
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (node->dispatch_event(UIEvents::WheelEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::wheel, screen_position, page_offset, viewport_position, offset, wheel_delta_x, wheel_delta_y, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors())) {
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->active_window()->scroll_by(wheel_delta_x, wheel_delta_y);
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
handled_event = EventResult::Handled;
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
}
LibWeb: Allow scrolling overflowed content with the mouse wheel :^) 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. :^)
2021-02-22 19:48:24 +01:00
}
LibWeb: Dispatch "wheel" event
2022-10-17 20:54:01 +03:00
return handled_event;
LibWeb: Plumb wheel events from widget layer to EventHandler
2021-02-22 19:45:41 +01:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
EventResult EventHandler::handle_mouseup(CSSPixelPoint viewport_position, CSSPixelPoint screen_position, u32 button, u32 buttons, u32 modifiers)
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
{
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (should_ignore_device_input_event())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->active_document()->update_layout();
LibWeb: Flush any pending layout updates before processing mouse events We want to make sure the layout and paint trees are up-to-date before handling any mouse events.
2022-03-16 18:50:56 +01:00
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
if (!paint_root())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Painting::Paintable> paintable;
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = target_for_mouse_position(viewport_position); result.has_value())
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
paintable = result->paintable;
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
if (paintable && paintable->wants_mouse_events()) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (paintable->handle_mouseup({}, viewport_position, button, modifiers) == Painting::Paintable::DispatchEventOfSameName::No)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Cancelled;
LibWeb: Two mouse event handling fixes - After letting a LayoutNode handle a mouseup, re-do the hit test since things may have changed. - Make sure we always update the document's hovered node.
2020-09-12 17:55:19 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
// Things may have changed as a consequence of Layout::Node::handle_mouseup(). Hit test again.
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
if (!paint_root())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = paint_root()->hit_test(viewport_position, Painting::HitTestType::Exact); result.has_value())
LibWeb: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
paintable = result->paintable;
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
auto handled_event = EventResult::Dropped;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
if (paintable) {
LibWeb: Try harder to find a suitable DOM node for mouse event dispatch 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. :^)
2022-10-23 17:53:02 +02:00
auto node = dom_node_for_event_dispatch(*paintable);
LibWeb: Dispatch a click event after mousedown+mouseup on same target
2022-02-07 13:27:17 +01:00
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
if (node) {
if (is<HTML::HTMLIFrameElement>(*node)) {
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (auto content_navigable = static_cast<HTML::HTMLIFrameElement&>(*node).content_navigable())
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
return content_navigable->event_handler().handle_mouseup(viewport_position.translated(compute_mouse_event_offset({}, *paintable)), screen_position, button, buttons, modifiers);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
}
LibWeb: Dispatch mouse events to topmost element instead of hit target 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.
2022-05-03 16:50:38 +02:00
// Search for the first parent of the hit target that's an element.
// "The click event type MUST be dispatched on the topmost event target indicated by the pointer." (https://www.w3.org/TR/uievents/#event-type-click)
// "The topmost event target MUST be the element highest in the rendering order which is capable of being an event target." (https://www.w3.org/TR/uievents/#topmost-event-target)
LibWeb: Fix a few const-ness issues
2023-02-25 10:44:51 -07:00
Layout::Node* layout_node;
LibWeb: Move code for finding the parent element into a helper function This exact same loop is repeated a couple of times.
2022-10-24 03:24:19 +02:00
if (!parent_element_for_event_dispatch(*paintable, node, layout_node)) {
LibWeb: Dispatch mouse events to topmost element instead of hit target 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.
2022-05-03 16:50:38 +02:00
// FIXME: This is pretty ugly but we need to bail out here.
goto after_node_use;
}
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto page_offset = compute_mouse_event_page_offset(viewport_position);
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto offset = compute_mouse_event_offset(page_offset, *layout_node->first_paintable());
LibWeb: Dispatch pointer events in EventHandler Now, along with the mouse events we also dispatch pointerup, pointerdown and pointermove. With this change shape painting works on https://excalidraw.com/
2024-11-21 21:35:49 +01:00
node->dispatch_event(UIEvents::PointerEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::pointerup, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
node->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::mouseup, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
handled_event = EventResult::Handled;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
LibWeb: Do not fire click event if mouseup/down elements do not match Click event logic should start as false, and after checking if the mousedown and subsequent mouseup have been on the same element, and if the node dispatches events it can become true. This fixes the issue that clicking anywhere on the page, then dragging the mouse on top of a link or button, then releasing triggers the link. This is also happening when selecting text, if the selection stops over a link, the page navigates.
2023-07-21 16:42:48 +02:00
bool run_activation_behavior = false;
LibWeb: Fire the contextmenu event on right click (if not holding shift) This now allows websites such as Discord, YouTube and your favourite "Right Click" xkcd comic to open a custom context menu when you right click. You can bypass this by holding shift, just like Firefox.
2023-05-21 20:29:30 +01:00
if (node.ptr() == m_mousedown_target) {
LibWeb: Add Web::UIEvents::MouseButton enum, drop dependency on LibGUI This was the only thing LibWeb needed from LibGUI, and we can just duplicate the enum in LibWeb and get rid of a bogus dependency.
2024-06-02 19:00:42 +02:00
if (button == UIEvents::MouseButton::Primary) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
run_activation_behavior = node->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::click, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Fire `auxclick` event on middle click Previously, no event was fired on middle click. This change also allows the UI to open a link in a new tab on middle click.
2024-06-21 22:00:19 +01:00
} else if (button == UIEvents::MouseButton::Middle) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
run_activation_behavior = node->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::auxclick, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Add Web::UIEvents::MouseButton enum, drop dependency on LibGUI This was the only thing LibWeb needed from LibGUI, and we can just duplicate the enum in LibWeb and get rid of a bogus dependency.
2024-06-02 19:00:42 +02:00
} else if (button == UIEvents::MouseButton::Secondary) {
LibWeb: Run page activation behavior when skipping context menu events We partially supported this feature, but not enough for the chrome's context menu to open. We now propagate the event back to the chrome.
2024-04-25 10:04:11 -04:00
// Allow the user to bypass custom context menus by holding shift, like Firefox.
LibWeb: Add Web::UIEvents::KeyCode and KeyModifier enums, drop Kernel This was the last Kernel header we had. Move the definitions we need into a UIEvents header similar to MouseButton.
2024-06-06 13:29:08 -06:00
if ((modifiers & UIEvents::Mod_Shift) == 0)
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
run_activation_behavior = node->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::contextmenu, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Run page activation behavior when skipping context menu events We partially supported this feature, but not enough for the chrome's context menu to open. We now propagate the event back to the chrome.
2024-04-25 10:04:11 -04:00
else
run_activation_behavior = true;
}
LibWeb: Skip anchor activation behavior if the click event was cancelled
2022-04-08 21:48:00 -03:00
}
if (run_activation_behavior) {
LibWeb: Update `EventHandler::handle_mouseup` to use navigables
2023-09-13 15:25:45 +02:00
// FIXME: Currently cannot spawn a new top-level
LibWeb: Skip anchor activation behavior if the click event was cancelled
2022-04-08 21:48:00 -03:00
// browsing context for new tab operations, because the new
// top-level browsing context would be in another process. To
// fix this, there needs to be some way to be able to
// communicate with browsing contexts in remote WebContent
// processes, and then step 8 of this algorithm needs to be
LibWeb: Update `EventHandler::handle_mouseup` to use navigables
2023-09-13 15:25:45 +02:00
// implemented in Navigable::choose_a_navigable:
LibWeb: Skip anchor activation behavior if the click event was cancelled
2022-04-08 21:48:00 -03:00
//
LibWeb: Update `EventHandler::handle_mouseup` to use navigables
2023-09-13 15:25:45 +02:00
// https://html.spec.whatwg.org/multipage/document-sequences.html#the-rules-for-choosing-a-navigable
LibWeb: Always use Navigable to translate CSS positions to top-level
2024-02-04 03:36:24 -07:00
LibWeb: Fix context menu and select dropdown position in iframe
2025-01-14 03:14:22 +01:00
auto top_level_viewport_position = m_navigable->to_top_level_position(viewport_position);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
if (GC::Ptr<HTML::HTMLAnchorElement const> link = node->enclosing_link_element()) {
GC::Ref<DOM::Document> document = *m_navigable->active_document();
LibWeb: Skip anchor activation behavior if the click event was cancelled
2022-04-08 21:48:00 -03:00
auto href = link->href();
LibWeb: Use correct URL parsing methods throughout LibWeb There are essentially 3 URL parsing AOs defined by the spec: 1. Parse a URL 2. Encoding parse a URL 3. Encoding parse a URL and serialize the result Further, these are replicated between the Document and the ESO. This patch defines these methods in accordance with the spec and updates existing users to invoke the correct method. In places where the correct method is ambiguous, we use the encoding parser to preserve existing ad- hoc behavior.
2024-12-06 16:24:08 -05:00
auto url = document->encoding_parse_url(href);
LibWeb: Port Document encoding_parse_url and parse_url to Optional<URL> This ports two more APIs away from URL::is_valid.
2025-01-23 19:40:57 +13:00
if (url.has_value()) {
if (button == UIEvents::MouseButton::Primary && (modifiers & UIEvents::Mod_PlatformCtrl) != 0) {
m_navigable->page().client().page_did_click_link(*url, link->target().to_byte_string(), modifiers);
} else if (button == UIEvents::MouseButton::Middle) {
m_navigable->page().client().page_did_middle_click_link(*url, link->target().to_byte_string(), modifiers);
} else if (button == UIEvents::MouseButton::Secondary) {
m_navigable->page().client().page_did_request_link_context_menu(top_level_viewport_position, *url, link->target().to_byte_string(), modifiers);
}
LibWeb: Bring handling of anchor elements closer to spec 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.
2022-03-15 14:37:58 +00:00
}
LibWeb: Add Web::UIEvents::MouseButton enum, drop dependency on LibGUI This was the only thing LibWeb needed from LibGUI, and we can just duplicate the enum in LibWeb and get rid of a bogus dependency.
2024-06-02 19:00:42 +02:00
} else if (button == UIEvents::MouseButton::Secondary) {
LibWeb: Skip anchor activation behavior if the click event was cancelled
2022-04-08 21:48:00 -03:00
if (is<HTML::HTMLImageElement>(*node)) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto& image_element = as<HTML::HTMLImageElement>(*node);
LibWeb: Use correct URL parsing methods throughout LibWeb There are essentially 3 URL parsing AOs defined by the spec: 1. Parse a URL 2. Encoding parse a URL 3. Encoding parse a URL and serialize the result Further, these are replicated between the Document and the ESO. This patch defines these methods in accordance with the spec and updates existing users to invoke the correct method. In places where the correct method is ambiguous, we use the encoding parser to preserve existing ad- hoc behavior.
2024-12-06 16:24:08 -05:00
auto image_url = image_element.document().encoding_parse_url(image_element.src());
LibWeb: Port Document encoding_parse_url and parse_url to Optional<URL> This ports two more APIs away from URL::is_valid.
2025-01-23 19:40:57 +13:00
if (image_url.has_value()) {
Optional<Gfx::Bitmap const*> bitmap;
if (image_element.immutable_bitmap())
bitmap = image_element.immutable_bitmap()->bitmap();
UI: Prevent crash when right clicking on an unloaded image
2025-01-10 20:33:27 +11:00
LibWeb: Port Document encoding_parse_url and parse_url to Optional<URL> This ports two more APIs away from URL::is_valid.
2025-01-23 19:40:57 +13:00
m_navigable->page().client().page_did_request_image_context_menu(top_level_viewport_position, *image_url, "", modifiers, bitmap);
}
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
} else if (is<HTML::HTMLMediaElement>(*node)) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto& media_element = as<HTML::HTMLMediaElement>(*node);
Browser+LibWeb+WebContent: Broadcast video element context menu requests This just sets up the IPC to notify the browser process of context menu requests on video elements. The IPC contains a few pieces of information about the state of the video element.
2023-05-15 09:42:56 -04:00
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
Page::MediaContextMenu menu {
LibWeb: Port Document encoding_parse_url and parse_url to Optional<URL> This ports two more APIs away from URL::is_valid.
2025-01-23 19:40:57 +13:00
.media_url = *media_element.document().encoding_parse_url(media_element.current_src()),
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
.is_video = is<HTML::HTMLVideoElement>(*node),
.is_playing = media_element.potentially_playing(),
Ladybird+LibWeb+WebContent: Add context menu controls for muting audio
2023-06-16 11:29:54 -04:00
.is_muted = media_element.muted(),
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
.has_user_agent_controls = media_element.has_attribute(HTML::AttributeNames::controls),
.is_looping = media_element.has_attribute(HTML::AttributeNames::loop),
};
Browser+LibWeb+WebContent: Broadcast video element context menu requests This just sets up the IPC to notify the browser process of context menu requests on video elements. The IPC contains a few pieces of information about the state of the video element.
2023-05-15 09:42:56 -04:00
LibWeb: Fix context menu and select dropdown position in iframe
2025-01-14 03:14:22 +01:00
m_navigable->page().did_request_media_context_menu(media_element.unique_id(), top_level_viewport_position, "", modifiers, move(menu));
LibWeb: Make BrowsingContex::page() return a Page& This exposed a whole slew of now-unnecessary null checks. :^) Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-12-03 20:29:37 +13:00
} else {
LibWeb: Fix context menu and select dropdown position in iframe
2025-01-14 03:14:22 +01:00
m_navigable->page().client().page_did_request_context_menu(top_level_viewport_position);
LibWeb: Skip anchor activation behavior if the click event was cancelled
2022-04-08 21:48:00 -03:00
}
LibWeb: Select correct context menu when right clicking image
2022-04-07 22:43:30 +01:00
}
LibWeb: Bring handling of anchor elements closer to spec 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.
2022-03-15 14:37:58 +00:00
}
LibWeb: Dispatch "click" event on input control associated with <label> For example, in the following HTML: ```html <label> <input type="radio" name="fruit" value="apple" id="radio1"> <span class="box"></span> </label> ``` When any descendant of a <label> element is clicked, a "click" event must be dispatched on the <input> element nested within the <label>, in addition to the "click" event dispatched on the clicked descendant. Previously, this behavior was implemented only for text node descendants by "overriding" the mouse event target using `mouse_event_target()` in the TextPaintable. This approach was incorrect because it was limited to text nodes, whereas the behavior should apply to any box. Moreover, the "click" event for the input control must be dispatched *in addition* to the event on the clicked element, rather than redirecting it.
2024-11-20 21:31:13 +01:00
if (auto* input_control = input_control_associated_with_ancestor_label_element(*paintable)) {
if (button == UIEvents::MouseButton::Primary) {
input_control->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::click, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
}
}
LibWeb: Dispatch a click event after mousedown+mouseup on same target
2022-02-07 13:27:17 +01:00
}
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb: Dispatch mouse events to topmost element instead of hit target 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.
2022-05-03 16:50:38 +02:00
after_node_use:
LibWeb: Update input/textarea selection on document selection change This causes UI interactions with the document selection to also update the input and textarea DOM selection state. Note that we switch around the order of focusing a DOM node and setting the selection, so we allow the focus event to override whatever selection we came up with.
2024-08-26 13:07:57 +02:00
if (button == UIEvents::MouseButton::Primary) {
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
m_in_mouse_selection = false;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
m_mouse_selection_target = nullptr;
LibWeb: Update input/textarea selection on document selection change This causes UI interactions with the document selection to also update the input and textarea DOM selection state. Note that we switch around the order of focusing a DOM node and setting the selection, so we allow the focus event to override whatever selection we came up with.
2024-08-26 13:07:57 +02:00
}
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
return handled_event;
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
EventResult EventHandler::handle_mousedown(CSSPixelPoint viewport_position, CSSPixelPoint screen_position, u32 button, u32 buttons, u32 modifiers)
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
{
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (should_ignore_device_input_event())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->active_document()->update_layout();
LibWeb: Flush any pending layout updates before processing mouse events We want to make sure the layout and paint trees are up-to-date before handling any mouse events.
2022-03-16 18:50:56 +01:00
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
if (!paint_root())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<DOM::Document> document = *m_navigable->active_document();
GC::Ptr<DOM::Node> node;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
{
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Painting::Paintable> paintable;
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = target_for_mouse_position(viewport_position); result.has_value())
LibWeb: Make hit testing functions return Optional<HitTestResult> Using "HitTestResult with null paintable" as a way to signal misses was unnecessarily confusing. Let's use Optional instead. :^)
2022-03-21 11:11:05 +01:00
paintable = result->paintable;
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
else
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
auto pointer_events = paintable->computed_values().pointer_events();
LibWeb: Add `pointer-events: all` This is basically the same as `auto` in the spec, so let's just treat them as identical for now. Gets rid of some Discord CSS parser spam. :^)
2022-02-07 17:19:33 +00:00
// FIXME: Handle other values for pointer-events.
LibWeb: Ignore "pointer-events: none" elements in hit_test
2022-10-19 13:46:48 +03:00
VERIFY(pointer_events != CSS::PointerEvents::None);
LibWeb: Don't assume we hit a layout node when handling mousedown events Regression from the introduction of CSS pointer-events in ec43f7a2b0840a97c6d093066750dd28840d9587.
2021-10-19 12:53:22 +02:00
LibWeb: Try harder to find a suitable DOM node for mouse event dispatch 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. :^)
2022-10-23 17:53:02 +02:00
node = dom_node_for_event_dispatch(*paintable);
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
document->set_hovered_node(node);
LibWeb: Two mouse event handling fixes - After letting a LayoutNode handle a mouseup, re-do the hit test since things may have changed. - Make sure we always update the document's hovered node.
2020-09-12 17:55:19 +02:00
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
if (paintable->wants_mouse_events()) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (paintable->handle_mousedown({}, viewport_position, button, modifiers) == Painting::Paintable::DispatchEventOfSameName::No)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Cancelled;
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
}
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
if (!node)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
if (is<HTML::HTMLIFrameElement>(*node)) {
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (auto content_navigable = static_cast<HTML::HTMLIFrameElement&>(*node).content_navigable())
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
return content_navigable->event_handler().handle_mousedown(viewport_position.translated(compute_mouse_event_offset({}, *paintable)), screen_position, button, buttons, modifiers);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
}
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->page().set_focused_navigable({}, m_navigable);
LibWeb: Add "focused frame" concept, one focused Frame per Page Focus currently only moves when doing a mousedown in a frame.
2020-08-14 11:33:20 +02:00
LibWeb: Dispatch mouse events to topmost element instead of hit target 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.
2022-05-03 16:50:38 +02:00
// Search for the first parent of the hit target that's an element.
// "The click event type MUST be dispatched on the topmost event target indicated by the pointer." (https://www.w3.org/TR/uievents/#event-type-click)
// "The topmost event target MUST be the element highest in the rendering order which is capable of being an event target." (https://www.w3.org/TR/uievents/#topmost-event-target)
LibWeb: Fix a few const-ness issues
2023-02-25 10:44:51 -07:00
Layout::Node* layout_node;
LibWeb: Move code for finding the parent element into a helper function This exact same loop is repeated a couple of times.
2022-10-24 03:24:19 +02:00
if (!parent_element_for_event_dispatch(*paintable, node, layout_node))
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Dispatch mouse events to topmost element instead of hit target 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.
2022-05-03 16:50:38 +02:00
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated 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.
2022-08-28 13:42:07 +02:00
m_mousedown_target = node.ptr();
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto page_offset = compute_mouse_event_page_offset(viewport_position);
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto offset = compute_mouse_event_offset(page_offset, *layout_node->first_paintable());
LibWeb: Dispatch pointer events in EventHandler Now, along with the mouse events we also dispatch pointerup, pointerdown and pointermove. With this change shape painting works on https://excalidraw.com/
2024-11-21 21:35:49 +01:00
node->dispatch_event(UIEvents::PointerEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::pointerdown, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
node->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::mousedown, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
}
// NOTE: Dispatching an event may have disturbed the world.
LibWeb/DOM: Rename Node::{paint => paintable}_box() It returns a PaintableBox, not a 'PaintBox'.
2023-04-20 16:01:16 +01:00
if (!paint_root() || paint_root() != node->document().paintable_box())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Accepted;
LibWeb: Check if layout node is still present after dispatch_event Fixes https://github.com/SerenityOS/serenity/issues/2638 Dispatching an event can change the document. Therefore another check for the layout_root needs to be done.
2020-07-10 23:43:25 +02:00
LibWeb: Add Web::UIEvents::MouseButton enum, drop dependency on LibGUI This was the only thing LibWeb needed from LibGUI, and we can just duplicate the enum in LibWeb and get rid of a bogus dependency.
2024-06-02 19:00:42 +02:00
if (button == UIEvents::MouseButton::Primary) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = paint_root()->hit_test(viewport_position, Painting::HitTestType::TextCursor); result.has_value()) {
LibWeb: Bring handling of anchor elements closer to spec 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.
2022-03-15 14:37:58 +00:00
auto paintable = result->paintable;
LibWeb: Introduce variable `dom_node` in EventHandler::handle_mousedown to make the code more readable
2024-08-19 16:22:31 -03:00
auto dom_node = paintable->dom_node();
if (dom_node) {
LibWeb: Update focus target when handling mousedown events 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.
2022-02-06 19:28:09 +01:00
// See if we want to focus something.
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<DOM::Node> focus_candidate;
LibWeb: Dispatch "click" event on input control associated with <label> For example, in the following HTML: ```html <label> <input type="radio" name="fruit" value="apple" id="radio1"> <span class="box"></span> </label> ``` When any descendant of a <label> element is clicked, a "click" event must be dispatched on the <input> element nested within the <label>, in addition to the "click" event dispatched on the clicked descendant. Previously, this behavior was implemented only for text node descendants by "overriding" the mouse event target using `mouse_event_target()` in the TextPaintable. This approach was incorrect because it was limited to text nodes, whereas the behavior should apply to any box. Moreover, the "click" event for the input control must be dispatched *in addition* to the event on the clicked element, rather than redirecting it.
2024-11-20 21:31:13 +01:00
if (auto* input_control = input_control_associated_with_ancestor_label_element(*paintable)) {
focus_candidate = input_control;
} else {
for (auto candidate = node; candidate; candidate = candidate->parent_or_shadow_host()) {
if (candidate->is_focusable()) {
focus_candidate = candidate;
break;
}
LibWeb: Update focus target when handling mousedown events 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.
2022-02-06 19:28:09 +01:00
}
}
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
// When a user activates a click focusable focusable area, the user agent must run the focusing steps on the focusable area with focus trigger set to "click".
// Spec Note: Note that focusing is not an activation behavior, i.e. calling the click() method on an element or dispatching a synthetic click event on it won't cause the element to get focused.
if (focus_candidate)
HTML::run_focusing_steps(focus_candidate, nullptr, "click"sv);
else if (auto* focused_element = document->focused_element())
HTML::run_unfocusing_steps(focused_element);
LibWeb: Implement user-select This implements all values of user-select.
2025-01-08 01:51:29 +01:00
// https://drafts.csswg.org/css-ui/#valdef-user-select-none
// Attempting to start a selection in an element where user-select is none, such as by clicking in it or starting
// a drag in it, must not cause a pre-existing selection to become unselected or to be affected in any way.
auto user_select = paintable->layout_node().user_select_used_value();
if (user_select != CSS::UserSelect::None) {
auto target = document->active_input_events_target();
if (target) {
m_in_mouse_selection = true;
m_mouse_selection_target = target;
if (modifiers & UIEvents::KeyModifier::Mod_Shift) {
target->set_selection_focus(*dom_node, result->index_in_node);
LibWeb: Extend text selection when left clicking and holding shift
2024-06-05 16:01:31 +01:00
} else {
LibWeb: Implement user-select This implements all values of user-select.
2025-01-08 01:51:29 +01:00
target->set_selection_anchor(*dom_node, result->index_in_node);
}
} else if (!focus_candidate) {
m_in_mouse_selection = true;
if (auto selection = document->get_selection()) {
auto anchor_node = selection->anchor_node();
if (anchor_node && modifiers & UIEvents::KeyModifier::Mod_Shift) {
set_user_selection(*anchor_node, selection->anchor_offset(), *dom_node, result->index_in_node, selection, user_select);
} else {
set_user_selection(*dom_node, result->index_in_node, *dom_node, result->index_in_node, selection, user_select);
}
LibWeb: Extend text selection when left clicking and holding shift
2024-06-05 16:01:31 +01:00
}
LibWeb: Use DOM Selection instead of ad-hoc layout tree selection Before this patch, we were expressing the current selection as a range between two points in the layout tree. This was a made-up concept I called LayoutRange (2x LayoutPosition) and as it turns out, we don't actually need it! Instead, we can just use the Selection API from the Selection API spec. This API expresses selection in terms of the DOM, and we already had many of the building blocks implemented. To ensure that selections get visually updated when the underlying Range of an active Selection is programmatically manipulated, Range now has an "associated Selection". If a range is updated while associated with a selection, we recompute layout tree selection states and repaint the page to make it user-visible.
2023-01-11 19:48:53 +01:00
}
LibWeb: Update focus target when handling mousedown events 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.
2022-02-06 19:28:09 +01:00
}
LibWeb: Specialize hit testing for text cursor purposes The text cursor follows slightly different "intuitive" rules than the regular hit testing. Clicking past the right edge of a text box should still "hit" the text box, and place the cursor at its end, for example. We solve this by adding a HitTestType enum that is passed to hit_test() and determines whether past-the-edge candidates are considered.
2020-08-05 16:55:56 +02:00
}
LibWeb: Add Page context menu request Pages can request a context menu on right click. This is plumbed through the PageClient.
2020-06-27 14:21:58 -06:00
}
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
EventResult EventHandler::handle_mousemove(CSSPixelPoint viewport_position, CSSPixelPoint screen_position, u32 buttons, u32 modifiers)
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
{
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (should_ignore_device_input_event())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->active_document()->update_layout();
LibWeb: Flush any pending layout updates before processing mouse events We want to make sure the layout and paint trees are up-to-date before handling any mouse events.
2022-03-16 18:50:56 +01:00
LibWeb: Move hit testing to the painting tree
2022-03-11 00:03:28 +01:00
if (!paint_root())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
auto& document = *m_navigable->active_document();
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
bool hovered_node_changed = false;
bool is_hovering_link = false;
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
Gfx::Cursor hovered_node_cursor = Gfx::StandardCursor::None;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Painting::Paintable> paintable;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
Optional<int> start_index;
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = target_for_mouse_position(viewport_position); result.has_value()) {
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
paintable = result->paintable;
start_index = result->index_in_node;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
}
LibWeb: Move HTML classes into the Web::HTML namespace
2020-07-28 18:20:36 +02:00
const HTML::HTMLAnchorElement* hovered_link_element = nullptr;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
if (paintable) {
if (paintable->wants_mouse_events()) {
LibWeb: Add Paintable::dom_node() convenience accessor
2022-03-21 11:19:02 +01:00
document.set_hovered_node(paintable->dom_node());
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (paintable->handle_mousemove({}, viewport_position, buttons, modifiers) == Painting::Paintable::DispatchEventOfSameName::No)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Cancelled;
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
// FIXME: It feels a bit aggressive to always update the cursor like this.
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->page().client().page_did_request_cursor_change(Gfx::StandardCursor::None);
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
}
LibWeb: Try harder to find a suitable DOM node for mouse event dispatch 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. :^)
2022-10-23 17:53:02 +02:00
auto node = dom_node_for_event_dispatch(*paintable);
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
LibWeb: Move HTML classes into the Web::HTML namespace
2020-07-28 18:20:36 +02:00
if (node && is<HTML::HTMLIFrameElement>(*node)) {
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (auto content_navigable = static_cast<HTML::HTMLIFrameElement&>(*node).content_navigable())
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
return content_navigable->event_handler().handle_mousemove(viewport_position.translated(compute_mouse_event_offset({}, *paintable)), screen_position, buttons, modifiers);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
auto cursor_data = paintable->computed_values().cursor();
LibWeb: Refactor all LabelableNode subclasses + input event handling :^) 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.
2022-03-14 23:05:55 +00:00
auto pointer_events = paintable->computed_values().pointer_events();
LibWeb: Add `pointer-events: all` This is basically the same as `auto` in the spec, so let's just treat them as identical for now. Gets rid of some Discord CSS parser spam. :^)
2022-02-07 17:19:33 +00:00
// FIXME: Handle other values for pointer-events.
LibWeb: Ignore "pointer-events: none" elements in hit_test
2022-10-19 13:46:48 +03:00
VERIFY(pointer_events != CSS::PointerEvents::None);
LibWeb: Add initial version of pointer-events CSS property
2021-10-05 19:47:13 +01:00
LibWeb: Pick the correct DOM node for mouse-move events This makes hovering over the link in the following HTML snippet work, i.e. the tooltip is shown and the link target is shown at the bottom of the browser window: <html lang="en"><head><style> .site-link{display:inline-block} .site-link:before{content:"derp"} .site-link::after{content:"";display:block} </style></head><body><a class="site-link" href="#" title="Tooltip, maybe!"></a>
2022-11-07 18:22:33 +01:00
// Search for the first parent of the hit target that's an element.
// "The click event type MUST be dispatched on the topmost event target indicated by the pointer." (https://www.w3.org/TR/uievents/#event-type-click)
// "The topmost event target MUST be the element highest in the rendering order which is capable of being an event target." (https://www.w3.org/TR/uievents/#topmost-event-target)
LibWeb: Fix a few const-ness issues
2023-02-25 10:44:51 -07:00
Layout::Node* layout_node;
LibWeb: Pick the correct DOM node for mouse-move events This makes hovering over the link in the following HTML snippet work, i.e. the tooltip is shown and the link target is shown at the bottom of the browser window: <html lang="en"><head><style> .site-link{display:inline-block} .site-link:before{content:"derp"} .site-link::after{content:"";display:block} </style></head><body><a class="site-link" href="#" title="Tooltip, maybe!"></a>
2022-11-07 18:22:33 +01:00
bool found_parent_element = parent_element_for_event_dispatch(*paintable, node, layout_node);
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated 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.
2022-08-28 13:42:07 +02:00
hovered_node_changed = node.ptr() != document.hovered_node();
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
document.set_hovered_node(node);
LibWeb: Pick the correct DOM node for mouse-move events This makes hovering over the link in the following HTML snippet work, i.e. the tooltip is shown and the link target is shown at the bottom of the browser window: <html lang="en"><head><style> .site-link{display:inline-block} .site-link:before{content:"derp"} .site-link::after{content:"";display:block} </style></head><body><a class="site-link" href="#" title="Tooltip, maybe!"></a>
2022-11-07 18:22:33 +01:00
if (found_parent_element) {
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
hovered_link_element = node->enclosing_link_element();
LibWeb: Remove ancient HTML_DEBUG debug logging
2020-11-19 22:21:16 +01:00
if (hovered_link_element)
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
is_hovering_link = true;
LibWeb: Call `page_did_request_cursor_change` with CSS cursor
2021-02-21 20:15:00 +00:00
LibWeb: Display an IBeam cursor by default when mousing over a text node We now check the type of the layout node at the current mouse position when determining which cursor to display during a mouse move event.
2024-02-12 18:34:06 +00:00
if (paintable->layout_node().is_text_node()) {
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
hovered_node_cursor = resolve_cursor(*paintable->layout_node().parent(), cursor_data, Gfx::StandardCursor::IBeam);
LibWeb: Set cursor on mousemove for non-text elements
2022-02-15 21:48:48 -05:00
} else if (node->is_element()) {
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
hovered_node_cursor = resolve_cursor(static_cast<Layout::NodeWithStyle&>(*layout_node), cursor_data, Gfx::StandardCursor::Arrow);
LibWeb: Add initial version of pointer-events CSS property
2021-10-05 19:47:13 +01:00
}
LibWeb: Call `page_did_request_cursor_change` with CSS cursor
2021-02-21 20:15:00 +00:00
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto page_offset = compute_mouse_event_page_offset(viewport_position);
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto offset = compute_mouse_event_offset(page_offset, *layout_node->first_paintable());
Ladybird+LibWeb: Add MouseEvent screenX and screenY support
2023-09-08 18:48:44 +02:00
auto movement = compute_mouse_event_movement(screen_position);
LibWeb: Allow JS event handlers to stop propagation of mousemove events This follows similar logic to keydown events.
2023-12-02 10:54:17 -05:00
Ladybird+LibWeb: Add MouseEvent screenX and screenY support
2023-09-08 18:48:44 +02:00
m_mousemove_previous_screen_position = screen_position;
LibWeb: Allow JS event handlers to stop propagation of mousemove events This follows similar logic to keydown events.
2023-12-02 10:54:17 -05:00
LibWeb: Dispatch pointer events in EventHandler Now, along with the mouse events we also dispatch pointerup, pointerdown and pointermove. With this change shape painting works on https://excalidraw.com/
2024-11-21 21:35:49 +01:00
bool continue_ = node->dispatch_event(UIEvents::PointerEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::pointermove, screen_position, page_offset, viewport_position, offset, movement, UIEvents::MouseButton::Primary, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
if (!continue_)
return EventResult::Cancelled;
continue_ = node->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::mousemove, screen_position, page_offset, viewport_position, offset, movement, UIEvents::MouseButton::Primary, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Allow JS event handlers to stop propagation of mousemove events This follows similar logic to keydown events.
2023-12-02 10:54:17 -05:00
if (!continue_)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Cancelled;
LibWeb: Allow JS event handlers to stop propagation of mousemove events This follows similar logic to keydown events.
2023-12-02 10:54:17 -05:00
LibWeb: Abort event handling if underlying layout tree disappears We didn't notice that the layout tree had disappeared after dispatching a mousedown event, because we only checked EventHandler::layout_root() which happily returned the *new* layout tree after a window.reload(). This patch fixes that by verifying that the frame is still showing the same DOM's layout tree after event dispatch. Fixes #4224.
2020-11-29 16:39:56 +01:00
// NOTE: Dispatching an event may have disturbed the world.
LibWeb/DOM: Rename Node::{paint => paintable}_box() It returns a PaintableBox, not a 'PaintBox'.
2023-04-20 16:01:16 +01:00
if (!paint_root() || paint_root() != node->document().paintable_box())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Accepted;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
if (m_in_mouse_selection) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto hit = paint_root()->hit_test(viewport_position, Painting::HitTestType::TextCursor);
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
if (m_mouse_selection_target) {
LibWeb: Only set selection focus if an associated DOM node was found The relation from a paintable to a DOM node is not always set.
2024-12-06 16:32:20 +01:00
if (hit.has_value() && hit->paintable->dom_node())
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
m_mouse_selection_target->set_selection_focus(*hit->paintable->dom_node(), hit->index_in_node);
} else {
if (start_index.has_value() && hit.has_value() && hit->dom_node()) {
if (auto selection = document.get_selection()) {
auto anchor_node = selection->anchor_node();
if (anchor_node) {
if (&anchor_node->root() == &hit->dom_node()->root())
LibWeb: Implement user-select This implements all values of user-select.
2025-01-08 01:51:29 +01:00
set_user_selection(*anchor_node, selection->anchor_offset(), *hit->paintable->dom_node(), hit->index_in_node, selection, hit->paintable->layout_node().user_select_used_value());
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
} else {
LibWeb: Implement user-select This implements all values of user-select.
2025-01-08 01:51:29 +01:00
set_user_selection(*hit->paintable->dom_node(), hit->index_in_node, *hit->paintable->dom_node(), hit->index_in_node, selection, hit->paintable->layout_node().user_select_used_value());
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
}
}
LibWeb: Don't update selection if start and end node roots differ This allows selection to work within shadow roots and prevents the selection being cleared if the mouse moves outside of the current document or shadow root.
2024-07-02 10:17:47 +01:00
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
document.set_needs_display();
}
LibWeb: Specialize hit testing for text cursor purposes The text cursor follows slightly different "intuitive" rules than the regular hit testing. Clicking past the right edge of a text box should still "hit" the text box, and place the cursor at its end, for example. We solve this by adding a HitTestType enum that is passed to hit_test() and determines whether past-the-edge candidates are considered.
2020-08-05 16:55:56 +02:00
}
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
}
LibWeb: Change cursor to IBeam when hovering text This is what most browsers do, hopefully it isn't too silly :^)
2020-08-17 12:54:41 +02:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
auto& page = m_navigable->page();
LibWeb: Make Frame point weakly to Page This patch makes Page weakable and allows page-less frames to exist. Page is single-owner, and Frame is multiple-owner, so it's not sound for Frame to assume its containing Page will stick around for its own entire lifetime. Fixes #3976.
2020-11-12 18:23:05 +01:00
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 12:17:29 +00:00
// FIXME: This check is only approximate. ImageCursors from the same CursorStyleValue share bitmaps, but may repaint them.
// So comparing them does not tell you if they are the same image. Also, the image may change even if the hovered
// node does not.
if (page.current_cursor() != hovered_node_cursor || hovered_node_changed) {
LibWeb: Remember page's cursor and request change only when it changes Before, on *every* mouse-move event, `page_did_request_cursor_change()` virtual function would get called, requesting to change cursor to the event's mouse position's cursor. Now, the page keeps track of the last cursor change that was requested ("page's current cursor") and only requests cursor change again if and only if the current cursor is not already the one that is required.
2024-04-20 10:13:39 +00:00
page.set_current_cursor(hovered_node_cursor);
page.client().page_did_request_cursor_change(hovered_node_cursor);
}
LibWeb: Make BrowsingContex::page() return a Page& This exposed a whole slew of now-unnecessary null checks. :^) Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-12-03 20:29:37 +13:00
if (hovered_node_changed) {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<HTML::HTMLElement const> hovered_html_element = document.hovered_node() ? document.hovered_node()->enclosing_html_element_with_attribute(HTML::AttributeNames::title) : nullptr;
LibWeb: Leave tooltip or unhover link only if page entered/hovered one Before, on a mouse-move event, if the hovered html element did not have a tooltip or it was not a link, `page_did_leave_tooltip_area()` and `page_did_unhover_link()` virtual functions would get called. Now, the page remembers if it is in a tooltip area or hovering a link and only informs of leaving or unhovering only if it was.
2024-04-20 10:14:31 +00:00
LibWeb: Make BrowsingContex::page() return a Page& This exposed a whole slew of now-unnecessary null checks. :^) Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-12-03 20:29:37 +13:00
if (hovered_html_element && hovered_html_element->title().has_value()) {
LibWeb: Leave tooltip or unhover link only if page entered/hovered one Before, on a mouse-move event, if the hovered html element did not have a tooltip or it was not a link, `page_did_leave_tooltip_area()` and `page_did_unhover_link()` virtual functions would get called. Now, the page remembers if it is in a tooltip area or hovering a link and only informs of leaving or unhovering only if it was.
2024-04-20 10:14:31 +00:00
page.set_is_in_tooltip_area(true);
LibWeb+UI/Qt: Display 'title' tooltips only when the mouse stops moving Now instead of sending the position in which the user entered the tooltip area, send just the text, and let the chrome figure out how to display it. In the case of Qt, wait for 600 milliseconds of no mouse movement, then display it under the mouse cursor.
2024-07-02 14:16:24 +02:00
page.client().page_did_enter_tooltip_area(hovered_html_element->title()->to_byte_string());
LibWeb: Leave tooltip or unhover link only if page entered/hovered one Before, on a mouse-move event, if the hovered html element did not have a tooltip or it was not a link, `page_did_leave_tooltip_area()` and `page_did_unhover_link()` virtual functions would get called. Now, the page remembers if it is in a tooltip area or hovering a link and only informs of leaving or unhovering only if it was.
2024-04-20 10:14:31 +00:00
} else if (page.is_in_tooltip_area()) {
page.set_is_in_tooltip_area(false);
LibWeb: Make BrowsingContex::page() return a Page& This exposed a whole slew of now-unnecessary null checks. :^) Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-12-03 20:29:37 +13:00
page.client().page_did_leave_tooltip_area();
LibWeb: Make Frame point weakly to Page This patch makes Page weakable and allows page-less frames to exist. Page is single-owner, and Frame is multiple-owner, so it's not sound for Frame to assume its containing Page will stick around for its own entire lifetime. Fixes #3976.
2020-11-12 18:23:05 +01:00
}
LibWeb: Leave tooltip or unhover link only if page entered/hovered one Before, on a mouse-move event, if the hovered html element did not have a tooltip or it was not a link, `page_did_leave_tooltip_area()` and `page_did_unhover_link()` virtual functions would get called. Now, the page remembers if it is in a tooltip area or hovering a link and only informs of leaving or unhovering only if it was.
2024-04-20 10:14:31 +00:00
if (is_hovering_link) {
page.set_is_hovering_link(true);
LibWeb: Port Document encoding_parse_url and parse_url to Optional<URL> This ports two more APIs away from URL::is_valid.
2025-01-23 19:40:57 +13:00
page.client().page_did_hover_link(*document.encoding_parse_url(hovered_link_element->href()));
LibWeb: Leave tooltip or unhover link only if page entered/hovered one Before, on a mouse-move event, if the hovered html element did not have a tooltip or it was not a link, `page_did_leave_tooltip_area()` and `page_did_unhover_link()` virtual functions would get called. Now, the page remembers if it is in a tooltip area or hovering a link and only informs of leaving or unhovering only if it was.
2024-04-20 10:14:31 +00:00
} else if (page.is_hovering_link()) {
page.set_is_hovering_link(false);
LibWeb: Make BrowsingContex::page() return a Page& This exposed a whole slew of now-unnecessary null checks. :^) Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-12-03 20:29:37 +13:00
page.client().page_did_unhover_link();
LibWeb: Leave tooltip or unhover link only if page entered/hovered one Before, on a mouse-move event, if the hovered html element did not have a tooltip or it was not a link, `page_did_leave_tooltip_area()` and `page_did_unhover_link()` virtual functions would get called. Now, the page remembers if it is in a tooltip area or hovering a link and only informs of leaving or unhovering only if it was.
2024-04-20 10:14:31 +00:00
}
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb: Make BrowsingContex::page() return a Page& This exposed a whole slew of now-unnecessary null checks. :^) Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-12-03 20:29:37 +13:00
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
EventResult EventHandler::handle_doubleclick(CSSPixelPoint viewport_position, CSSPixelPoint screen_position, u32 button, u32 buttons, u32 modifiers)
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
{
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (should_ignore_device_input_event())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
LibWeb: Move the navigable's cursor position to be owned by the document Navigables are re-used for navigations within the same tab. Its current ownership of the cursor position is a bit ad-hoc, so nothing in the spec indicates when to reset the cursor, nor do we manually do so. So when a cursor update happens on one page, that cursor is retained on the next page. Instead, let's have the document own the cursor. Each navigation results in a new document, thus we don't need to worry about resetting cursors. This also makes many of the callsites feel nicer. We were previously often going from the node, to the document, to the navigable, to the cursor. This patch removes the navigable hop.
2024-08-02 07:31:40 -04:00
auto& document = *m_navigable->active_document();
document.update_layout();
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
if (!paint_root())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Painting::Paintable> paintable;
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = target_for_mouse_position(viewport_position); result.has_value())
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
paintable = result->paintable;
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
else
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
auto pointer_events = paintable->computed_values().pointer_events();
// FIXME: Handle other values for pointer-events.
if (pointer_events == CSS::PointerEvents::None)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Cancelled;
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
LibWeb: Try harder to find a suitable DOM node for mouse event dispatch 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. :^)
2022-10-23 17:53:02 +02:00
auto node = dom_node_for_event_dispatch(*paintable);
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
if (paintable->wants_mouse_events()) {
// FIXME: Handle double clicks.
}
if (!node)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
if (is<HTML::HTMLIFrameElement>(*node)) {
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (auto content_navigable = static_cast<HTML::HTMLIFrameElement&>(*node).content_navigable())
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
return content_navigable->event_handler().handle_doubleclick(viewport_position.translated(compute_mouse_event_offset({}, *paintable)), screen_position, button, buttons, modifiers);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
}
// Search for the first parent of the hit target that's an element.
// "The topmost event target MUST be the element highest in the rendering order which is capable of being an event target." (https://www.w3.org/TR/uievents/#topmost-event-target)
LibWeb: Fix a few const-ness issues
2023-02-25 10:44:51 -07:00
Layout::Node* layout_node;
LibWeb: Move code for finding the parent element into a helper function This exact same loop is repeated a couple of times.
2022-10-24 03:24:19 +02:00
if (!parent_element_for_event_dispatch(*paintable, node, layout_node))
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto page_offset = compute_mouse_event_page_offset(viewport_position);
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto offset = compute_mouse_event_offset(page_offset, *layout_node->first_paintable());
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
node->dispatch_event(UIEvents::MouseEvent::create_from_platform_event(node->realm(), UIEvents::EventNames::dblclick, screen_position, page_offset, viewport_position, offset, {}, button, buttons, modifiers).release_value_but_fixme_should_propagate_errors());
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
LibWeb: Make doubleclicking select the nearest word
2022-06-14 21:57:29 +02:00
// NOTE: Dispatching an event may have disturbed the world.
LibWeb/DOM: Rename Node::{paint => paintable}_box() It returns a PaintableBox, not a 'PaintBox'.
2023-04-20 16:01:16 +01:00
if (!paint_root() || paint_root() != node->document().paintable_box())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Accepted;
LibWeb: Make doubleclicking select the nearest word
2022-06-14 21:57:29 +02:00
LibWeb: Add Web::UIEvents::MouseButton enum, drop dependency on LibGUI This was the only thing LibWeb needed from LibGUI, and we can just duplicate the enum in LibWeb and get rid of a bogus dependency.
2024-06-02 19:00:42 +02:00
if (button == UIEvents::MouseButton::Primary) {
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
if (auto result = paint_root()->hit_test(viewport_position, Painting::HitTestType::TextCursor); result.has_value()) {
LibWeb: Store "text for rendering" in TextPaintable Instead of TextPaintable fragments being an offset+length view into the layout node, they are now a view into the paintable instead. This removes an awkward time window where we'd have bogus state in text fragments after layout invalidation but before relayout. It also makes the code slightly nicer in general, since there's less mixing of layout and painting concepts.
2024-03-18 10:25:57 +01:00
if (!result->paintable->dom_node())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Accepted;
LibWeb: Store "text for rendering" in TextPaintable Instead of TextPaintable fragments being an offset+length view into the layout node, they are now a view into the paintable instead. This removes an awkward time window where we'd have bogus state in text fragments after layout invalidation but before relayout. It also makes the code slightly nicer in general, since there's less mixing of layout and painting concepts.
2024-03-18 10:25:57 +01:00
if (!is<Painting::TextPaintable>(*result->paintable))
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Accepted;
LibWeb: Store "text for rendering" in TextPaintable Instead of TextPaintable fragments being an offset+length view into the layout node, they are now a view into the paintable instead. This removes an awkward time window where we'd have bogus state in text fragments after layout invalidation but before relayout. It also makes the code slightly nicer in general, since there's less mixing of layout and painting concepts.
2024-03-18 10:25:57 +01:00
auto& hit_paintable = static_cast<Painting::TextPaintable const&>(*result->paintable);
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto& hit_dom_node = const_cast<DOM::Text&>(as<DOM::Text>(*hit_paintable.dom_node()));
LibWeb: Use cached word segmenter for word selection in EventHandler
2024-10-30 17:16:12 +01:00
auto previous_boundary = hit_dom_node.word_segmenter().previous_boundary(result->index_in_node, Unicode::Segmenter::Inclusive::Yes).value_or(0);
auto next_boundary = hit_dom_node.word_segmenter().next_boundary(result->index_in_node).value_or(hit_dom_node.length());
LibWeb: Make doubleclicking select the nearest word
2022-06-14 21:57:29 +02:00
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
auto target = document.active_input_events_target();
if (target) {
target->set_selection_anchor(hit_dom_node, previous_boundary);
target->set_selection_focus(hit_dom_node, next_boundary);
} else if (auto selection = node->document().get_selection()) {
LibWeb: Implement user-select This implements all values of user-select.
2025-01-08 01:51:29 +01:00
set_user_selection(hit_dom_node, previous_boundary, hit_dom_node, next_boundary, selection, hit_paintable.layout_node().user_select_used_value());
LibWeb: Use DOM Selection instead of ad-hoc layout tree selection Before this patch, we were expressing the current selection as a range between two points in the layout tree. This was a made-up concept I called LayoutRange (2x LayoutPosition) and as it turns out, we don't actually need it! Instead, we can just use the Selection API from the Selection API spec. This API expresses selection in terms of the DOM, and we already had many of the building blocks implemented. To ensure that selections get visually updated when the underlying Range of an active Selection is programmatically manipulated, Range now has an "associated Selection". If a range is updated while associated with a selection, we recompute layout tree selection states and repaint the page to make it user-visible.
2023-01-11 19:48:53 +01:00
}
LibWeb: Make doubleclicking select the nearest word
2022-06-14 21:57:29 +02:00
}
}
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Add stub implementation for handling doubleclicks
2022-06-14 19:38:00 +02:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
EventResult EventHandler::handle_drag_and_drop_event(DragEvent::Type type, CSSPixelPoint viewport_position, CSSPixelPoint screen_position, u32 button, u32 buttons, u32 modifiers, Vector<HTML::SelectedFile> files)
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
{
if (!m_navigable->active_document())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
auto& document = *m_navigable->active_document();
document.update_layout();
if (!paint_root())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Painting::Paintable> paintable;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (auto result = target_for_mouse_position(viewport_position); result.has_value())
paintable = result->paintable;
else
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
auto node = dom_node_for_event_dispatch(*paintable);
if (!node)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
if (is<HTML::HTMLIFrameElement>(*node)) {
if (auto content_navigable = static_cast<HTML::HTMLIFrameElement&>(*node).content_navigable())
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
return content_navigable->event_handler().handle_drag_and_drop_event(type, viewport_position.translated(compute_mouse_event_offset({}, *paintable)), screen_position, button, buttons, modifiers, move(files));
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
}
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
auto page_offset = compute_mouse_event_page_offset(viewport_position);
LibWeb: Use paintables when calculating mouse event offset
2024-12-20 15:52:47 +11:00
auto offset = compute_mouse_event_offset(page_offset, *paintable);
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
switch (type) {
case DragEvent::Type::DragStart:
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
return m_drag_and_drop_event_handler->handle_drag_start(document.realm(), screen_position, page_offset, viewport_position, offset, button, buttons, modifiers, move(files));
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
case DragEvent::Type::DragMove:
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
return m_drag_and_drop_event_handler->handle_drag_move(document.realm(), document, *node, screen_position, page_offset, viewport_position, offset, button, buttons, modifiers);
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
case DragEvent::Type::DragEnd:
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
return m_drag_and_drop_event_handler->handle_drag_leave(document.realm(), screen_position, page_offset, viewport_position, offset, button, buttons, modifiers);
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
case DragEvent::Type::Drop:
LibWeb: Fix MouseEvent position values The clientX and clientY values are, as per the spec, the offset from the viewport. This makes them actually be that and also fixes up the calculations for offsetX, offsetY, pageX and pageY. I assume all of these got messed up in some sort of refactor in the past. The spec comment from the now-removed compute_mouse_event_client_offset() function sadly has no convenient place to be anymore so, for now, it is just gone as well. Personally, I think it'd make sense to refactor a lot of this file so that not every mouse event repeats a large chunk of (almost) identical code. That way there'd be a nice place to put the comment without repeating it all over the file. But that is out of the scope of this PR. Also: I know, offsetX and Y are not fully fixed yet, they still don't ignore the element's CSS transforms but I am working on that in a new PR.
2024-11-15 17:36:32 +01:00
return m_drag_and_drop_event_handler->handle_drop(document.realm(), screen_position, page_offset, viewport_position, offset, button, buttons, modifiers);
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
}
VERIFY_NOT_REACHED();
}
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
bool EventHandler::focus_next_element()
LibWeb: Allow inserting text at the cursor by typing characters :^) This works everywhere right now, but it's obviously not going to stay that way forever. :^) Note that this does not advance the cursor correctly for whitespace since the cursor is DOM-based and doesn't take whitespace collapsing into account yet.
2020-08-02 12:10:01 +02:00
{
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
return false;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
return false;
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
auto set_focus_to_first_focusable_element = [&]() {
auto* element = m_navigable->active_document()->first_child_of_type<DOM::Element>();
for (; element; element = element->next_element_in_pre_order()) {
if (element->is_focusable()) {
m_navigable->active_document()->set_focused_element(element);
return true;
}
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
}
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
return false;
};
auto* element = m_navigable->active_document()->focused_element();
if (!element)
return set_focus_to_first_focusable_element();
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
for (element = element->next_element_in_pre_order(); element && !element->is_focusable(); element = element->next_element_in_pre_order())
;
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
if (!element)
return set_focus_to_first_focusable_element();
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->active_document()->set_focused_element(element);
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
return true;
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
}
bool EventHandler::focus_previous_element()
{
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb: Implement EventHandler::focus_previous_element() This implements EventHandler::focus_previous_element() so we can cycle backwards through focusable elements on a web page with Shift+Tab.
2022-02-08 21:23:43 +01:00
return false;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
return false;
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
auto set_focus_to_last_focusable_element = [&]() {
// FIXME: This often returns the HTML element itself, which has no previous sibling.
auto* element = m_navigable->active_document()->last_child_of_type<DOM::Element>();
for (; element; element = element->previous_element_in_pre_order()) {
if (element->is_focusable()) {
m_navigable->active_document()->set_focused_element(element);
return true;
}
LibWeb: Implement EventHandler::focus_previous_element() This implements EventHandler::focus_previous_element() so we can cycle backwards through focusable elements on a web page with Shift+Tab.
2022-02-08 21:23:43 +01:00
}
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
return false;
};
auto* element = m_navigable->active_document()->focused_element();
if (!element)
return set_focus_to_last_focusable_element();
LibWeb: Implement EventHandler::focus_previous_element() This implements EventHandler::focus_previous_element() so we can cycle backwards through focusable elements on a web page with Shift+Tab.
2022-02-08 21:23:43 +01:00
for (element = element->previous_element_in_pre_order(); element && !element->is_focusable(); element = element->previous_element_in_pre_order())
;
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
if (!element)
return set_focus_to_last_focusable_element();
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
m_navigable->active_document()->set_focused_element(element);
LibWeb: Properly handle when (shift+)tab wraps around the page We have support for using (shift+)tab to move focus to the next/previous element on the page. However, there were several ways for this to crash as written. This updates our implementation to check if we did not find a node to move focus to, and to reset focus to the first/last node in the document. This doesn't seem to work when wrapping around from the first to the last node. A FIXME has been added for that, as this would already not work before this patch (the main focus here is not crashing).
2024-10-09 17:06:05 -04:00
return true;
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
}
LibWeb: Don't update input text if Ctrl or Alt are pressed With this change, input elements ignore keypresses while Ctrl or Alt are pressed. This matches the behavior of Chrome and Firefox
2024-01-30 20:09:33 +00:00
constexpr bool should_ignore_keydown_event(u32 code_point, u32 modifiers)
LibWeb: Do nothing when pressing modifier keys in HTML contenteditable 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.
2021-05-18 13:13:58 +02:00
{
LibWeb: Add Web::UIEvents::KeyCode and KeyModifier enums, drop Kernel This was the last Kernel header we had. Move the definitions we need into a UIEvents header similar to MouseButton.
2024-06-06 13:29:08 -06:00
if (modifiers & (UIEvents::KeyModifier::Mod_Ctrl | UIEvents::KeyModifier::Mod_Alt | UIEvents::KeyModifier::Mod_Super))
LibWeb: Don't update input text if Ctrl or Alt are pressed With this change, input elements ignore keypresses while Ctrl or Alt are pressed. This matches the behavior of Chrome and Firefox
2024-01-30 20:09:33 +00:00
return true;
Everywhere: codepoint => code point
2021-06-01 10:01:11 +02:00
// FIXME: There are probably also keys with non-zero code points that should be filtered out.
LibWeb: Add key code 'Esc' to ignored Keydown Events in EventHandler This filters out the key code 'Esc' so it won't be printed to editable text nodes, e.g. text <input> elements.
2022-02-19 22:22:45 +01:00
return code_point == 0 || code_point == 27;
LibWeb: Do nothing when pressing modifier keys in HTML contenteditable 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.
2021-05-18 13:13:58 +02:00
}
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
EventResult EventHandler::fire_keyboard_event(FlyString const& event_name, HTML::Navigable& navigable, UIEvents::KeyCode key, u32 modifiers, u32 code_point, bool repeat)
LibWeb: Make keyboard events properly fire into a focused iframe 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.
2022-11-05 15:36:03 +00:00
{
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<DOM::Document> document = navigable.active_document();
LibWeb: Make keyboard events properly fire into a focused iframe 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.
2022-11-05 15:36:03 +00:00
if (!document)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Exit event handlers if active document is not fully active Fixes https://github.com/SerenityOS/serenity/issues/21304
2023-10-03 15:35:07 +02:00
if (!document->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Make keyboard events properly fire into a focused iframe 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.
2022-11-05 15:36:03 +00:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
if (GC::Ptr<DOM::Element> focused_element = document->focused_element()) {
LibWeb: Rename BrowsingContextContainer => NavigableContainer 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>
2022-12-12 12:20:02 +01:00
if (is<HTML::NavigableContainer>(*focused_element)) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto& navigable_container = as<HTML::NavigableContainer>(*focused_element);
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (navigable_container.content_navigable())
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
return fire_keyboard_event(event_name, *navigable_container.content_navigable(), key, modifiers, code_point, repeat);
LibWeb: Make keyboard events properly fire into a focused iframe 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.
2022-11-05 15:36:03 +00:00
}
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
auto event = UIEvents::KeyboardEvent::create_from_platform_event(document->realm(), event_name, key, modifiers, code_point, repeat);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return focused_element->dispatch_event(event) ? EventResult::Accepted : EventResult::Cancelled;
LibWeb: Make keyboard events properly fire into a focused iframe 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.
2022-11-05 15:36:03 +00:00
}
Everywhere: Fix a few comment typos
2022-11-09 10:56:12 -05:00
// FIXME: De-duplicate this. This is just to prevent wasting a KeyboardEvent allocation when recursing into an (i)frame.
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
auto event = UIEvents::KeyboardEvent::create_from_platform_event(document->realm(), event_name, key, modifiers, code_point, repeat);
LibWeb: Make keyboard events properly fire into a focused iframe 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.
2022-11-05 15:36:03 +00:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr target = document->body() ?: &document->root();
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return target->dispatch_event(event) ? EventResult::Accepted : EventResult::Cancelled;
LibWeb: Make keyboard events properly fire into a focused iframe 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.
2022-11-05 15:36:03 +00:00
}
LibWeb: Only fire keypress events if the key press produced a character For example, pressing just the shift key should not producde a keypress event.
2024-10-08 17:15:55 -04:00
// https://w3c.github.io/uievents/#unicode-character-categories
static bool produces_character_value(u32 code_point)
{
// A subset of the General Category values that are defined for each Unicode code point. This subset contains all
// the Letter (Ll, Lm, Lo, Lt, Lu), Number (Nd, Nl, No), Punctuation (Pc, Pd, Pe, Pf, Pi, Po, Ps) and Symbol (Sc,
// Sk, Sm, So) category values.
return Unicode::code_point_has_letter_general_category(code_point)
|| Unicode::code_point_has_number_general_category(code_point)
|| Unicode::code_point_has_punctuation_general_category(code_point)
|| Unicode::code_point_has_symbol_general_category(code_point);
}
LibWeb: Fire keypress event for Enter, Shift+Enter, and Ctrl+Enter keys For web compat and interop with other engines, this change makes us fire “keypress” events for the Enter key and for the combination of the Enter key with the Shift or Ctrl keys — despite the fact the UI Events spec states at https://w3c.github.io/uievents/#event-type-keypress it must be fired “if and only if that key normally produces a character value”. See https://github.com/w3c/uievents/issues/183#issuecomment-448091687 and https://github.com/w3c/uievents/issues/266#issuecomment-1887917756.
2025-01-24 16:25:59 +09:00
// https://github.com/w3c/uievents/issues/183#issuecomment-448091687
static bool is_enter_key_or_interoperable_enter_key_combo(UIEvents::KeyCode key, u32 modifiers)
{
if (key != UIEvents::KeyCode::Key_Return)
return false;
if (!modifiers)
return true;
if (modifiers & (UIEvents::KeyModifier::Mod_Shift | UIEvents::KeyModifier::Mod_Ctrl))
return true;
return false;
}
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
EventResult EventHandler::input_event(FlyString const& event_name, FlyString const& input_type, HTML::Navigable& navigable, u32 code_point)
{
auto document = navigable.active_document();
if (!document)
return EventResult::Dropped;
if (!document->is_fully_active())
return EventResult::Dropped;
UIEvents::InputEventInit input_event_init;
if (!is_unicode_control(code_point)) {
input_event_init.data = String::from_code_point(code_point);
}
input_event_init.input_type = input_type;
if (auto* focused_element = document->focused_element()) {
if (is<HTML::NavigableContainer>(*focused_element)) {
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
auto& navigable_container = as<HTML::NavigableContainer>(*focused_element);
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
if (navigable_container.content_navigable())
return input_event(event_name, input_type, *navigable_container.content_navigable(), code_point);
}
auto event = UIEvents::InputEvent::create_from_platform_event(document->realm(), event_name, input_event_init);
return focused_element->dispatch_event(event) ? EventResult::Accepted : EventResult::Cancelled;
}
auto event = UIEvents::InputEvent::create_from_platform_event(document->realm(), event_name, input_event_init);
if (auto* body = document->body())
return body->dispatch_event(event) ? EventResult::Accepted : EventResult::Cancelled;
return document->root().dispatch_event(event) ? EventResult::Accepted : EventResult::Cancelled;
}
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
EventResult EventHandler::handle_keydown(UIEvents::KeyCode key, u32 modifiers, u32 code_point, bool repeat)
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
{
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (!m_navigable->active_document()->is_fully_active())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Dropped;
LibWeb: Use strong pointers and null checks in handle_keydown()
2021-10-12 14:44:00 +02:00
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
auto dispatch_result = fire_keyboard_event(UIEvents::EventNames::keydown, m_navigable, key, modifiers, code_point, repeat);
LibWeb: Fire keydown and keypress events sooner Fire the events before handling any close requests or selection changes. Pages must have an opportunity to cancel the events.
2024-10-09 07:39:08 -04:00
if (dispatch_result != EventResult::Accepted)
return dispatch_result;
LibWeb: Only fire keypress events if the key press produced a character For example, pressing just the shift key should not producde a keypress event.
2024-10-08 17:15:55 -04:00
// https://w3c.github.io/uievents/#event-type-keypress
// If supported by a user agent, this event MUST be dispatched when a key is pressed down, if and only if that key
// normally produces a character value.
LibWeb: Fire keypress event for Enter, Shift+Enter, and Ctrl+Enter keys For web compat and interop with other engines, this change makes us fire “keypress” events for the Enter key and for the combination of the Enter key with the Shift or Ctrl keys — despite the fact the UI Events spec states at https://w3c.github.io/uievents/#event-type-keypress it must be fired “if and only if that key normally produces a character value”. See https://github.com/w3c/uievents/issues/183#issuecomment-448091687 and https://github.com/w3c/uievents/issues/266#issuecomment-1887917756.
2025-01-24 16:25:59 +09:00
// AD-HOC: For web compat and for interop with other engines, we make an exception here for the Enter key. See:
// https://github.com/w3c/uievents/issues/183#issuecomment-448091687 and
// https://github.com/w3c/uievents/issues/266#issuecomment-1887917756
if (produces_character_value(code_point) || is_enter_key_or_interoperable_enter_key_combo(key, modifiers)) {
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
dispatch_result = fire_keyboard_event(UIEvents::EventNames::keypress, m_navigable, key, modifiers, code_point, repeat);
LibWeb: Only fire keypress events if the key press produced a character For example, pressing just the shift key should not producde a keypress event.
2024-10-08 17:15:55 -04:00
if (dispatch_result != EventResult::Accepted)
return dispatch_result;
}
LibWeb: Fire keydown and keypress events sooner Fire the events before handling any close requests or selection changes. Pages must have an opportunity to cancel the events.
2024-10-09 07:39:08 -04:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<DOM::Document> document = *m_navigable->active_document();
LibWeb: Use strong pointers and null checks in handle_keydown()
2021-10-12 14:44:00 +02:00
LibWeb: Add Web::UIEvents::KeyCode and KeyModifier enums, drop Kernel This was the last Kernel header we had. Move the definitions we need into a UIEvents header similar to MouseButton.
2024-06-06 13:29:08 -06:00
if (key == UIEvents::KeyCode::Key_Tab) {
if (modifiers & UIEvents::KeyModifier::Mod_Shift)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return focus_previous_element() ? EventResult::Handled : EventResult::Dropped;
return focus_next_element() ? EventResult::Handled : EventResult::Dropped;
LibWeb: Allow focusing individual (focusable) elements with Tab key You can now cycle through focusable elements (currently only hyperlinks are focusable) with the Tab key. The focus outline is rendered in a new FocusOutline paint phase.
2020-08-14 19:40:37 +02:00
}
LibWeb: Do not unconditionally prevent escape keys from being propagated We should only block the escape key from being sent to the web page if the CloseWatcherManager actually closed something. We use the escape key in the Inspector to cancel editing a DOM field. This unconditional early return broke this feature.
2024-08-19 22:50:55 -04:00
// https://html.spec.whatwg.org/multipage/interaction.html#close-requests
if (key == UIEvents::KeyCode::Key_Escape) {
// 7. Let closedSomething be the result of processing close watchers on document's relevant global object.
auto closed_something = document->window()->close_watcher_manager()->process_close_watchers();
// 8. If closedSomething is true, then return.
if (closed_something)
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Do not unconditionally prevent escape keys from being propagated We should only block the escape key from being sent to the web page if the CloseWatcherManager actually closed something. We use the escape key in the Inspector to cancel editing a DOM field. This unconditional early return broke this feature.
2024-08-19 22:50:55 -04:00
// 9. Alternative processing: Otherwise, there was nothing watching for a close request. The user agent may
// instead interpret this interaction as some other action, instead of interpreting it as a close request.
}
LibWeb: Implement CloseWatcher API This implements most of the CloseWatcher API from the html spec. AbortSignal support is unimplemented. Integration with dialogs and popovers is also unimplemented.
2024-06-21 22:53:05 +01:00
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
if (auto* element = m_navigable->active_document()->focused_element(); is<HTML::HTMLMediaElement>(element)) {
LibWeb: Allow toggling playback of media elements with keyboard controls This allows pausing/playing media elements with the space bar.
2023-07-02 21:40:46 -07:00
auto& media_element = static_cast<HTML::HTMLMediaElement&>(*element);
LibWeb: Don't handle media player key events if any modifier is pressed
2024-09-04 04:30:44 +01:00
if (media_element.handle_keydown({}, key, modifiers).release_value_but_fixme_should_propagate_errors())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Allow toggling playback of media elements with keyboard controls This allows pausing/playing media elements with the space bar.
2023-07-02 21:40:46 -07:00
}
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
auto* target = document->active_input_events_target();
if (target) {
if (key == UIEvents::KeyCode::Key_Backspace) {
LibWeb: Implement dispatching of "beforeinput" event
2024-10-20 21:54:32 +02:00
FIRE(input_event(UIEvents::EventNames::beforeinput, UIEvents::InputTypes::deleteContentBackward, m_navigable, code_point));
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
target->handle_delete(InputEventsTarget::DeleteDirection::Backward);
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
FIRE(input_event(UIEvents::EventNames::input, UIEvents::InputTypes::deleteContentBackward, m_navigable, code_point));
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Remove a bunch of pointless "else" in EventHandler
2021-10-12 14:44:52 +02:00
}
LibWeb: Allow modifying non-editable text selections with the keyboard This permits the user to use shift and the arrow/home/end keys to mutate the document selection. Arrow key presses on non-editable text without the shift key held has no effect. This behavior differs browser-to-browser. The behavior here most closely matches Firefox, though all browsers support this to some degree.
2024-09-07 17:56:32 -04:00
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
if (key == UIEvents::KeyCode::Key_Delete) {
LibWeb: Implement dispatching of "beforeinput" event
2024-10-20 21:54:32 +02:00
FIRE(input_event(UIEvents::EventNames::beforeinput, UIEvents::InputTypes::deleteContentForward, m_navigable, code_point));
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
target->handle_delete(InputEventsTarget::DeleteDirection::Forward);
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
FIRE(input_event(UIEvents::EventNames::input, UIEvents::InputTypes::deleteContentForward, m_navigable, code_point));
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Remove a bunch of pointless "else" in EventHandler
2021-10-12 14:44:52 +02:00
}
LibWeb: Update editable node selections with arrow/home/end keys When an editable node is focused and one of the arrow/home/end keys are pressed while shift is held, we will now create or update the document's selection. There is a bit of nuance to the behavior here, which matches how the cursor behaves in other engines. We will of course want to abstract this in the future to extend any non- editable node text selections. This also does not implement holding ctrl to jump by word, rather than grapheme.
2024-09-04 20:03:50 -04:00
LibWeb: Re-assign cmd+arrow key events to home/end keys on macOS In text documents, pressing the left/right arrow keys with the cmd key pressed should be treated as home/end key presses.
2024-09-05 12:43:07 -04:00
#if defined(AK_OS_MACOS)
if ((modifiers & UIEvents::Mod_Super) != 0) {
if (key == UIEvents::KeyCode::Key_Left) {
key = UIEvents::KeyCode::Key_Home;
modifiers &= ~UIEvents::Mod_Super;
}
if (key == UIEvents::KeyCode::Key_Right) {
key = UIEvents::KeyCode::Key_End;
modifiers &= ~UIEvents::Mod_Super;
}
}
#endif
LibWeb: Update editable node selections with arrow/home/end keys When an editable node is focused and one of the arrow/home/end keys are pressed while shift is held, we will now create or update the document's selection. There is a bit of nuance to the behavior here, which matches how the cursor behaves in other engines. We will of course want to abstract this in the future to extend any non- editable node text selections. This also does not implement holding ctrl to jump by word, rather than grapheme.
2024-09-04 20:03:50 -04:00
if (key == UIEvents::KeyCode::Key_Left || key == UIEvents::KeyCode::Key_Right) {
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
auto collapse = modifiers & UIEvents::Mod_Shift ? InputEventsTarget::CollapseSelection::No : InputEventsTarget::CollapseSelection::Yes;
if ((modifiers & UIEvents::Mod_PlatformWordJump) == 0) {
if (key == UIEvents::KeyCode::Key_Left) {
target->decrement_cursor_position_offset(collapse);
} else {
target->increment_cursor_position_offset(collapse);
LibWeb: Update editable node selections with arrow/home/end keys When an editable node is focused and one of the arrow/home/end keys are pressed while shift is held, we will now create or update the document's selection. There is a bit of nuance to the behavior here, which matches how the cursor behaves in other engines. We will of course want to abstract this in the future to extend any non- editable node text selections. This also does not implement holding ctrl to jump by word, rather than grapheme.
2024-09-04 20:03:50 -04:00
}
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
} else {
if (key == UIEvents::KeyCode::Key_Left) {
target->decrement_cursor_position_to_previous_word(collapse);
LibWeb: Allow modifying non-editable text selections with the keyboard This permits the user to use shift and the arrow/home/end keys to mutate the document selection. Arrow key presses on non-editable text without the shift key held has no effect. This behavior differs browser-to-browser. The behavior here most closely matches Firefox, though all browsers support this to some degree.
2024-09-07 17:56:32 -04:00
} else {
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
target->increment_cursor_position_to_next_word(collapse);
LibWeb: Allow modifying non-editable text selections with the keyboard This permits the user to use shift and the arrow/home/end keys to mutate the document selection. Arrow key presses on non-editable text without the shift key held has no effect. This behavior differs browser-to-browser. The behavior here most closely matches Firefox, though all browsers support this to some degree.
2024-09-07 17:56:32 -04:00
}
LibWeb: Replace some TODO() calls with FIXME comments in EventHandler 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.
2021-05-18 13:08:25 +02:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Remove a bunch of pointless "else" in EventHandler
2021-10-12 14:44:52 +02:00
}
LibWeb: Update editable node selections with arrow/home/end keys When an editable node is focused and one of the arrow/home/end keys are pressed while shift is held, we will now create or update the document's selection. There is a bit of nuance to the behavior here, which matches how the cursor behaves in other engines. We will of course want to abstract this in the future to extend any non- editable node text selections. This also does not implement holding ctrl to jump by word, rather than grapheme.
2024-09-04 20:03:50 -04:00
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
if (key == UIEvents::KeyCode::Key_Home) {
auto collapse = modifiers & UIEvents::Mod_Shift ? InputEventsTarget::CollapseSelection::No : InputEventsTarget::CollapseSelection::Yes;
target->move_cursor_to_start(collapse);
return EventResult::Handled;
}
LibWeb: Update editable node selections with arrow/home/end keys When an editable node is focused and one of the arrow/home/end keys are pressed while shift is held, we will now create or update the document's selection. There is a bit of nuance to the behavior here, which matches how the cursor behaves in other engines. We will of course want to abstract this in the future to extend any non- editable node text selections. This also does not implement holding ctrl to jump by word, rather than grapheme.
2024-09-04 20:03:50 -04:00
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
if (key == UIEvents::KeyCode::Key_End) {
auto collapse = modifiers & UIEvents::Mod_Shift ? InputEventsTarget::CollapseSelection::No : InputEventsTarget::CollapseSelection::Yes;
target->move_cursor_to_end(collapse);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Add support for navigating text <input> with End key
2022-02-19 18:42:08 +01:00
}
LibWeb: Update editable node selections with arrow/home/end keys When an editable node is focused and one of the arrow/home/end keys are pressed while shift is held, we will now create or update the document's selection. There is a bit of nuance to the behavior here, which matches how the cursor behaves in other engines. We will of course want to abstract this in the future to extend any non- editable node text selections. This also does not implement holding ctrl to jump by word, rather than grapheme.
2024-09-04 20:03:50 -04:00
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
if (key == UIEvents::KeyCode::Key_Return) {
LibWeb: Implement dispatching of "beforeinput" event
2024-10-20 21:54:32 +02:00
FIRE(input_event(UIEvents::EventNames::beforeinput, UIEvents::InputTypes::insertParagraph, m_navigable, code_point));
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
target->handle_return_key();
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
FIRE(input_event(UIEvents::EventNames::input, UIEvents::InputTypes::insertParagraph, m_navigable, code_point));
LibWeb: Support committing changes to <input> elements We currently fire the change event on <input> elements when they lose focus. The spec allows for us to also fire the event when changes are "committed", so long as such an action makes sense for the input type. This patch detects when the return key is entered in an <input> element and uses that as the commit action for text-related types. If no change has occurred since the last commit, no change event is fired.
2023-11-30 12:54:30 -05:00
}
LibWeb: Update editable node selections with arrow/home/end keys When an editable node is focused and one of the arrow/home/end keys are pressed while shift is held, we will now create or update the document's selection. There is a bit of nuance to the behavior here, which matches how the cursor behaves in other engines. We will of course want to abstract this in the future to extend any non- editable node text selections. This also does not implement holding ctrl to jump by word, rather than grapheme.
2024-09-04 20:03:50 -04:00
LibWeb: Don't update input text if Ctrl or Alt are pressed With this change, input elements ignore keypresses while Ctrl or Alt are pressed. This matches the behavior of Chrome and Firefox
2024-01-30 20:09:33 +00:00
// FIXME: Text editing shortcut keys (copy/paste etc.) should be handled here.
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
if (!should_ignore_keydown_event(code_point, modifiers)) {
LibWeb: Implement dispatching of "beforeinput" event
2024-10-20 21:54:32 +02:00
FIRE(input_event(UIEvents::EventNames::beforeinput, UIEvents::InputTypes::insertText, m_navigable, code_point));
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
target->handle_insert(String::from_code_point(code_point));
LibWeb: Implement dispatching of "input" event
2024-02-24 06:08:26 +01:00
FIRE(input_event(UIEvents::EventNames::input, UIEvents::InputTypes::insertText, m_navigable, code_point));
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Only allow editing of elements with contenteditable="true" We now respect the contenteditable HTML attribute and only let you edit content inside explicitly editable elements.
2020-08-02 16:05:59 +02:00
}
LibWeb: Fix ability to modify selection outside of inputs using keyboard Fixes regression introduced in a8077f79cc65a37f82078a6249f161e469e96c3a
2024-11-01 16:34:28 +01:00
} else if (auto selection = document->get_selection(); selection && !selection->is_collapsed()) {
if (modifiers & UIEvents::Mod_Shift) {
if (key == UIEvents::KeyCode::Key_Right) {
if (modifiers & UIEvents::Mod_PlatformWordJump)
selection->move_offset_to_next_word(false);
else
selection->move_offset_to_next_character(false);
return EventResult::Handled;
} else if (key == UIEvents::KeyCode::Key_Left) {
if (modifiers & UIEvents::Mod_PlatformWordJump)
selection->move_offset_to_previous_word(false);
else
selection->move_offset_to_previous_character(false);
return EventResult::Handled;
}
}
LibWeb: Allow inserting text at the cursor by typing characters :^) This works everywhere right now, but it's obviously not going to stay that way forever. :^) Note that this does not advance the cursor correctly for whitespace since the cursor is DOM-based and doesn't take whitespace collapsing into account yet.
2020-08-02 12:10:01 +02:00
}
LibWeb: Move editing stuff into EditEventHandler.
2020-12-01 23:35:47 +01:00
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
// FIXME: Implement scroll by line and by page instead of approximating the behavior of other browsers.
auto arrow_key_scroll_distance = 100;
auto page_scroll_distance = document->window()->inner_height() - (document->window()->outer_height() - document->window()->inner_height());
switch (key) {
case UIEvents::KeyCode::Key_Up:
case UIEvents::KeyCode::Key_Down:
if (modifiers && modifiers != UIEvents::KeyModifier::Mod_Ctrl)
break;
if (modifiers)
key == UIEvents::KeyCode::Key_Up ? document->scroll_to_the_beginning_of_the_document() : document->window()->scroll_by(0, INT64_MAX);
else
document->window()->scroll_by(0, key == UIEvents::KeyCode::Key_Up ? -arrow_key_scroll_distance : arrow_key_scroll_distance);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
case UIEvents::KeyCode::Key_Left:
case UIEvents::KeyCode::Key_Right:
LibWeb+UI: Detect and handle left vs. right modifier keys Our handling of left vs. right modifiers keys (shift, ctrl, etc.) was largely not to spec. This patch adds explicit UIEvents::KeyCode values for these keys, and updates the UI to match native key events to these keys (as best as we are able).
2024-10-09 08:56:55 -04:00
if (modifiers && modifiers != UIEvents::KeyModifier::Mod_Alt)
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
break;
if (modifiers)
document->page().traverse_the_history_by_delta(key == UIEvents::KeyCode::Key_Left ? -1 : 1);
else
document->window()->scroll_by(key == UIEvents::KeyCode::Key_Left ? -arrow_key_scroll_distance : arrow_key_scroll_distance, 0);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
case UIEvents::KeyCode::Key_PageUp:
case UIEvents::KeyCode::Key_PageDown:
LibWeb+UI: Detect and handle left vs. right modifier keys Our handling of left vs. right modifiers keys (shift, ctrl, etc.) was largely not to spec. This patch adds explicit UIEvents::KeyCode values for these keys, and updates the UI to match native key events to these keys (as best as we are able).
2024-10-09 08:56:55 -04:00
if (modifiers != UIEvents::KeyModifier::Mod_None)
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
break;
document->window()->scroll_by(0, key == UIEvents::KeyCode::Key_PageUp ? -page_scroll_distance : page_scroll_distance);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
case UIEvents::KeyCode::Key_Home:
document->scroll_to_the_beginning_of_the_document();
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
case UIEvents::KeyCode::Key_End:
document->window()->scroll_by(0, INT64_MAX);
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
return EventResult::Handled;
LibWeb: Scroll page and nav history with keyboard This patch implements basic keyboard functionality for page scrolling and history traversal.
2024-07-01 16:03:50 -04:00
default:
break;
}
LibWeb: Fire keydown and keypress events sooner Fire the events before handling any close requests or selection changes. Pages must have an opportunity to cancel the events.
2024-10-09 07:39:08 -04:00
return EventResult::Accepted;
LibWeb: Allow inserting text at the cursor by typing characters :^) This works everywhere right now, but it's obviously not going to stay that way forever. :^) Note that this does not advance the cursor correctly for whitespace since the cursor is DOM-based and doesn't take whitespace collapsing into account yet.
2020-08-02 12:10:01 +02:00
}
LibWeb/EventHandler: Ignore repeated keyup events Platforms such as X11 will typically send repeated keyRelease/keyup events as a result of auto-repeating: * KeyPress (initial) * KeyRelease (repeat) * KeyPress (repeat) * KeyRelease (repeat) * ad infinitum Make our EventHandler more spec-compliant by ignoring all repeated keyup events. This fixes long-pressing the arrow keys on https://playbiolab.com/.
2024-10-22 15:35:00 +02:00
EventResult EventHandler::handle_keyup(UIEvents::KeyCode key, u32 modifiers, u32 code_point, bool repeat)
LibWeb: Fire "keyup" events as well :^) This was easy, now that we have KeyboardEvent.
2021-09-28 15:39:35 +02:00
{
LibWeb/EventHandler: Ignore repeated keyup events Platforms such as X11 will typically send repeated keyRelease/keyup events as a result of auto-repeating: * KeyPress (initial) * KeyRelease (repeat) * KeyPress (repeat) * KeyRelease (repeat) * ad infinitum Make our EventHandler more spec-compliant by ignoring all repeated keyup events. This fixes long-pressing the arrow keys on https://playbiolab.com/.
2024-10-22 15:35:00 +02:00
// Keyup events as a result of auto-repeat are not fired.
// See: https://w3c.github.io/uievents/#events-keyboard-event-order
if (repeat)
return EventResult::Dropped;
UI+LibWeb+WebContent: Implement KeyEvent repeat property When a platform key press or release event is repeated, we now pass along a `repeat` flag to indicate that auto-repeating is happening. This flag eventually ends up in `KeyboardEvent.repeat`.
2024-10-22 15:32:42 +02:00
return fire_keyboard_event(UIEvents::EventNames::keyup, m_navigable, key, modifiers, code_point, false);
LibWeb: Fire "keyup" events as well :^) This was easy, now that we have KeyboardEvent.
2021-09-28 15:39:35 +02:00
}
LibWeb+WebContent+Ladybird: Add ability to paste text from clipboard Text can be pasted by pressing Ctrl/Cmd+V or by using button in the context menu. For now only the Qt client is supported.
2024-03-22 11:56:49 +01:00
void EventHandler::handle_paste(String const& text)
{
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
auto active_document = m_navigable->active_document();
LibWeb+WebContent+Ladybird: Add ability to paste text from clipboard Text can be pasted by pressing Ctrl/Cmd+V or by using button in the context menu. For now only the Qt client is supported.
2024-03-22 11:56:49 +01:00
if (!active_document)
return;
if (!active_document->is_fully_active())
return;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
auto* target = active_document->active_input_events_target();
if (!target)
return;
target->handle_insert(text);
LibWeb+WebContent+Ladybird: Add ability to paste text from clipboard Text can be pasted by pressing Ctrl/Cmd+V or by using button in the context menu. For now only the Qt client is supported.
2024-03-22 11:56:49 +01:00
}
LibWeb: Use paintable to represent event tracking node The use of layout nodes likely predated the paintable tree, but now there is no point in introducing another level of indirection.
2024-01-14 10:14:36 +01:00
void EventHandler::set_mouse_event_tracking_paintable(Painting::Paintable* paintable)
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
{
LibWeb: Use paintable to represent event tracking node The use of layout nodes likely predated the paintable tree, but now there is no point in introducing another level of indirection.
2024-01-14 10:14:36 +01:00
m_mouse_event_tracking_paintable = paintable;
LibWeb: Allow layout nodes to receive and track mouse events To implement form controls internally in LibWeb (necessary for multi process forms), we'll need the ability to handle events since we can't rely on LibGUI widgets anymore. A LayoutNode can now override wants_mouse_events() and if it returns true, it will now receive mousedown, mousemove and mouseup events. :^)
2020-09-11 18:15:47 +02:00
}
LibWeb: Implement deletion of more complex selections.
2020-12-03 18:46:56 +01:00
LibWeb: Support MouseEvent.{pageX,pageY} Unlike client{X,Y} which is relative to the current viewport, these offsets are relative to the left edge of the document (i.e they take scroll offset into account).
2022-12-31 16:40:36 +02:00
CSSPixelPoint EventHandler::compute_mouse_event_page_offset(CSSPixelPoint event_client_offset) const
{
// https://w3c.github.io/csswg-drafts/cssom-view/#dom-mouseevent-pagex
// FIXME: 1. If the event’s dispatch flag is set, return the horizontal coordinate of the position where the event occurred relative to the origin of the initial containing block and terminate these steps.
// 2. Let offset be the value of the scrollX attribute of the event’s associated Window object, if there is one, or zero otherwise.
LibWeb: Move event handling & cursor from BrowsingContext to Navigable This was a long standing FIXME since the introduction of navigables.
2024-04-26 16:59:04 +02:00
auto scroll_offset = m_navigable->active_document()->navigable()->viewport_scroll_offset();
LibWeb: Support MouseEvent.{pageX,pageY} Unlike client{X,Y} which is relative to the current viewport, these offsets are relative to the left edge of the document (i.e they take scroll offset into account).
2022-12-31 16:40:36 +02:00
// 3. Return the sum of offset and the value of the event’s clientX attribute.
LibWeb+WebContent: Convert BrowsingContext to new pixel units This fixes a few glitches. We no longer give the page double the width it should have, and we mark the correct area of the page as needing repainting.
2022-11-03 12:49:54 +00:00
return event_client_offset.translated(scroll_offset);
LibWeb: Support MouseEvent.{pageX,pageY} Unlike client{X,Y} which is relative to the current viewport, these offsets are relative to the left edge of the document (i.e they take scroll offset into account).
2022-12-31 16:40:36 +02:00
}
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
Ladybird+LibWeb: Add MouseEvent screenX and screenY support
2023-09-08 18:48:44 +02:00
CSSPixelPoint EventHandler::compute_mouse_event_movement(CSSPixelPoint screen_position) const
LibWeb: Partially implement MouseEvent.movementX/movementY Currently doesn't handle the mouse leaving and entering the window per the spec, and uses clientX/Y instead of screenX/Y. See FIXMEs.
2023-08-24 17:47:13 +02:00
{
// https://w3c.github.io/pointerlock/#dom-mouseevent-movementx
// The attributes movementX movementY must provide the change in position of the pointer,
// as if the values of screenX, screenY, were stored between two subsequent mousemove events eNow and ePrevious and the difference taken movementX = eNow.screenX-ePrevious.screenX.
Ladybird+LibWeb: Add MouseEvent screenX and screenY support
2023-09-08 18:48:44 +02:00
if (!m_mousemove_previous_screen_position.has_value())
LibWeb: Partially implement MouseEvent.movementX/movementY Currently doesn't handle the mouse leaving and entering the window per the spec, and uses clientX/Y instead of screenX/Y. See FIXMEs.
2023-08-24 17:47:13 +02:00
// When unlocked, the system cursor can exit and re-enter the user agent window.
// If it does so and the user agent was not the target of operating system mouse move events
// then the most recent pointer position will be unknown to the user agent and movementX/movementY can not be computed and must be set to zero.
// FIXME: For this to actually work, m_mousemove_previous_client_offset needs to be cleared when the mouse leaves the window
return { 0, 0 };
Ladybird+LibWeb: Add MouseEvent screenX and screenY support
2023-09-08 18:48:44 +02:00
return { screen_position.x() - m_mousemove_previous_screen_position.value().x(), screen_position.y() - m_mousemove_previous_screen_position.value().y() };
LibWeb: Partially implement MouseEvent.movementX/movementY Currently doesn't handle the mouse leaving and entering the window per the spec, and uses clientX/Y instead of screenX/Y. See FIXMEs.
2023-08-24 17:47:13 +02:00
}
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
Optional<EventHandler::Target> EventHandler::target_for_mouse_position(CSSPixelPoint position)
{
LibWeb: Use paintable to represent event tracking node The use of layout nodes likely predated the paintable tree, but now there is no point in introducing another level of indirection.
2024-01-14 10:14:36 +01:00
if (m_mouse_event_tracking_paintable) {
if (m_mouse_event_tracking_paintable->wants_mouse_events())
return Target { m_mouse_event_tracking_paintable, {} };
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
LibWeb: Use paintable to represent event tracking node The use of layout nodes likely predated the paintable tree, but now there is no point in introducing another level of indirection.
2024-01-14 10:14:36 +01:00
m_mouse_event_tracking_paintable = nullptr;
LibWeb: Clear the mouse event tracking node when it stops wanting events This can occur if a mouse click on a mouse event tracking node causes a page navigation. As the old document is torn down, the event handler may have a stale reference to the tracking node. If a subsequent mouse event occurs on that node, we would crash trying to access the node's styled properties that are no longer valid. To fix this, when we are deciding what node to send the event to, and we have a mouse event tracking node, check if that node still wants the event. If not, clear the tracking node.
2023-04-27 09:19:20 -04:00
}
if (auto result = paint_root()->hit_test(position, Painting::HitTestType::Exact); result.has_value())
return Target { result->paintable.ptr(), result->index_in_node };
return {};
}
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
bool EventHandler::should_ignore_device_input_event() const
{
// From the moment that the user agent is to initiate the drag-and-drop operation, until the end of the drag-and-drop
// operation, device input events (e.g. mouse and keyboard events) must be suppressed.
return m_drag_and_drop_event_handler->has_ongoing_drag_and_drop_operation();
}
LibWeb: Use paintable to represent event tracking node The use of layout nodes likely predated the paintable tree, but now there is no point in introducing another level of indirection.
2024-01-14 10:14:36 +01:00
void EventHandler::visit_edges(JS::Cell::Visitor& visitor) const
{
LibWeb: Begin implementing the drag-and-drop processing model The drag-and-drop processing model allows for users to drag around either elements within the DOM or objects completely outside the DOM. This drag event can either end without action (via cancellation or user input), or in a drop event, where the dragged object is dropped onto another element within the DOM. The processing model is rather large. This implements enough of it to allow the UI process to specifically handle dragging objects outside of the DOM onto the DOM. For example, dragging an image from the OS file manager onto a file-upload input element. This does not implement the ability to drag DOM elements.
2024-08-17 13:29:55 -04:00
m_drag_and_drop_event_handler->visit_edges(visitor);
LibWeb: Use paintable to represent event tracking node The use of layout nodes likely predated the paintable tree, but now there is no point in introducing another level of indirection.
2024-01-14 10:14:36 +01:00
visitor.visit(m_mouse_event_tracking_paintable);
LibWeb: Ensure EventHandler visits its mouse selection target We hold a raw pointer to the mouse selection target, which is a mixin- style class inherited only by JS::Cell classes. By not visiting this object, we sometime had a dangling reference to it after it had been garbage collected.
2025-02-26 20:40:10 -05:00
if (m_mouse_selection_target)
visitor.visit(m_mouse_selection_target->as_cell());
LibWeb: Use paintable to represent event tracking node The use of layout nodes likely predated the paintable tree, but now there is no point in introducing another level of indirection.
2024-01-14 10:14:36 +01:00
}
LibWeb: Use a Unicode text segmenter to select words on double-click We currently use a naive word segmentation, looking for ASCII spaces to mark a word boundary. Use LibUnicode's complete implementation instead.
2024-08-27 08:19:03 -04:00
Unicode::Segmenter& EventHandler::word_segmenter()
{
if (!m_word_segmenter)
LibWeb: Move initial creation of Unicode segmenters to the Document The expensive part of creating a segmenter is doing the locale and UCD data lookups at creation time. Instead of doing this once per text node, cache the segmenters on the document, and clone them as needed (cloning is much, much cheaper). On a profile loading Ladybird's GitHub repo, the following hot methods changed as follows: ChunkIterator ctor: 6.08% -> 0.21% Segmenter factory: 5.86% -> 0% Segmenter clone: N/A -> 0.09%
2024-09-22 10:03:23 -04:00
m_word_segmenter = m_navigable->active_document()->word_segmenter().clone();
LibWeb: Use a Unicode text segmenter to select words on double-click We currently use a naive word segmentation, looking for ASCII spaces to mark a word boundary. Use LibUnicode's complete implementation instead.
2024-08-27 08:19:03 -04:00
return *m_word_segmenter;
}
LibWeb: Add per-Frame EventHandler, handle mouse events recursively We now handle mouse events by recursing into subframes. This makes links, tooltips, etc, work inside <iframe> content.
2020-06-07 14:40:38 +02:00
}
Reference in a new issue Copy permalink