Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/TextPaintable.cpp

64 lines
2.2 KiB
C++
Raw Normal View History

LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Make Paintable ref-counted This will allow us to use a protective NonnullRefPtr to keep paintables alive while running arbitrary JavaScript in response to events.
2022-03-10 22:38:08 +01:00
#include <LibWeb/HTML/BrowsingContext.h>
#include <LibWeb/Layout/Label.h>
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
#include <LibWeb/Layout/LabelableNode.h>
LibWeb: Make Paintable ref-counted This will allow us to use a protective NonnullRefPtr to keep paintables alive while running arbitrary JavaScript in response to events.
2022-03-10 22:38:08 +01:00
#include <LibWeb/Page/EventHandler.h>
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
#include <LibWeb/Painting/TextPaintable.h>
namespace Web::Painting {
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_DEFINE_ALLOCATOR(TextPaintable);
LibWeb: Add calls to JS_{DECLARE,DEFINE}_ALLOCATOR()
2024-04-06 10:16:04 -07:00
LibWeb: Port rendered text to UTF-16 This migrates TextNode::text_for_rendering() to Utf16String and deals with the fallout. As a consequence, this effectively reverts commit 3df83dade80ad0dbcd27a8f6a6f1b540ff58c8f2. The layout test expecation file updates are because we now express text lengths and offsets in UTF-16 code units. The selection-over-multiple-code-units expectation file update actually represents a correctness fix. Our result now matches Firefox.
2025-07-25 09:34:41 -04:00
GC::Ref<TextPaintable> TextPaintable::create(Layout::TextNode const& layout_node, Utf16String text_for_rendering)
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
{
LibWeb: Port rendered text to UTF-16 This migrates TextNode::text_for_rendering() to Utf16String and deals with the fallout. As a consequence, this effectively reverts commit 3df83dade80ad0dbcd27a8f6a6f1b540ff58c8f2. The layout test expecation file updates are because we now express text lengths and offsets in UTF-16 code units. The selection-over-multiple-code-units expectation file update actually represents a correctness fix. Our result now matches Firefox.
2025-07-25 09:34:41 -04:00
return layout_node.heap().allocate<TextPaintable>(layout_node, move(text_for_rendering));
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
}
LibWeb: Port rendered text to UTF-16 This migrates TextNode::text_for_rendering() to Utf16String and deals with the fallout. As a consequence, this effectively reverts commit 3df83dade80ad0dbcd27a8f6a6f1b540ff58c8f2. The layout test expecation file updates are because we now express text lengths and offsets in UTF-16 code units. The selection-over-multiple-code-units expectation file update actually represents a correctness fix. Our result now matches Firefox.
2025-07-25 09:34:41 -04:00
TextPaintable::TextPaintable(Layout::TextNode const& layout_node, Utf16String text_for_rendering)
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
: Paintable(layout_node)
LibWeb: Port rendered text to UTF-16 This migrates TextNode::text_for_rendering() to Utf16String and deals with the fallout. As a consequence, this effectively reverts commit 3df83dade80ad0dbcd27a8f6a6f1b540ff58c8f2. The layout test expecation file updates are because we now express text lengths and offsets in UTF-16 code units. The selection-over-multiple-code-units expectation file update actually represents a correctness fix. Our result now matches Firefox.
2025-07-25 09:34:41 -04:00
, m_text_for_rendering(move(text_for_rendering))
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
{
}
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
bool TextPaintable::wants_mouse_events() const
{
return layout_node().first_ancestor_of_type<Layout::Label>();
}
LibWeb+WebContent+headless-browser: Use CSSPixels for PageClient events ...and also for hit testing, which is involved in most of them. Much of this is temporary conversions and other awkwardness, which should resolve itself as the rest of LibWeb is converted to these new types. Hopefully. :thousandyakstare:
2022-11-02 17:35:53 +00:00
TextPaintable::DispatchEventOfSameName TextPaintable::handle_mousedown(Badge<EventHandler>, CSSPixelPoint position, unsigned button, unsigned)
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
{
auto* label = layout_node().first_ancestor_of_type<Layout::Label>();
if (!label)
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
return DispatchEventOfSameName::No;
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
const_cast<Layout::Label*>(label)->handle_mousedown_on_label({}, position, button);
LibWeb: Remove unnecessary `const_cast`s from TextPaintable
2025-01-31 11:12:20 +01:00
navigable()->event_handler().set_mouse_event_tracking_paintable(this);
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
return DispatchEventOfSameName::Yes;
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
}
LibWeb+WebContent+headless-browser: Use CSSPixels for PageClient events ...and also for hit testing, which is involved in most of them. Much of this is temporary conversions and other awkwardness, which should resolve itself as the rest of LibWeb is converted to these new types. Hopefully. :thousandyakstare:
2022-11-02 17:35:53 +00:00
TextPaintable::DispatchEventOfSameName TextPaintable::handle_mouseup(Badge<EventHandler>, CSSPixelPoint position, unsigned button, unsigned)
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
{
auto* label = layout_node().first_ancestor_of_type<Layout::Label>();
if (!label)
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
return DispatchEventOfSameName::No;
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
const_cast<Layout::Label*>(label)->handle_mouseup_on_label({}, position, button);
LibWeb: Remove unnecessary `const_cast`s from TextPaintable
2025-01-31 11:12:20 +01:00
navigable()->event_handler().set_mouse_event_tracking_paintable(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
return DispatchEventOfSameName::Yes;
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
}
LibWeb+WebContent+headless-browser: Use CSSPixels for PageClient events ...and also for hit testing, which is involved in most of them. Much of this is temporary conversions and other awkwardness, which should resolve itself as the rest of LibWeb is converted to these new types. Hopefully. :thousandyakstare:
2022-11-02 17:35:53 +00:00
TextPaintable::DispatchEventOfSameName TextPaintable::handle_mousemove(Badge<EventHandler>, CSSPixelPoint position, unsigned button, unsigned)
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
{
auto* label = layout_node().first_ancestor_of_type<Layout::Label>();
if (!label)
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
return DispatchEventOfSameName::No;
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
const_cast<Layout::Label*>(label)->handle_mousemove_on_label({}, position, button);
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
return DispatchEventOfSameName::Yes;
LibWeb: Move mouse event and label logic from layout to painting tree Input events have nothing to do with layout, so let's not send them to layout nodes. The job of Paintable starts to become clear. It represents a paintable item that can be rendered into the viewport, which means it can also be targeted by the mouse cursor.
2022-03-10 22:46:35 +01:00
}
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
}
Reference in a new issue Copy permalink