Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-02 06:10:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Page/InputEvent.h

104 lines
2.3 KiB
C
Raw Normal View History

LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
/*
* Copyright (c) 2024, Tim Flynn <trflynn89@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/OwnPtr.h>
#include <AK/Variant.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 <AK/Vector.h>
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
#include <LibGfx/Point.h>
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
#include <LibIPC/Forward.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/HTML/SelectedFile.h>
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
#include <LibWeb/PixelUnits.h>
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
#include <LibWeb/UIEvents/KeyCode.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+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
namespace Web {
struct ChromeInputData {
virtual ~ChromeInputData() = default;
};
struct KeyEvent {
enum class Type {
KeyDown,
KeyUp,
};
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
KeyEvent clone_without_chrome_data() const;
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
Type type;
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
UIEvents::KeyCode key { UIEvents::KeyCode::Key_Invalid };
UIEvents::KeyModifier modifiers { UIEvents::KeyModifier::Mod_None };
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
u32 code_point { 0 };
OwnPtr<ChromeInputData> chrome_data;
};
struct MouseEvent {
enum class Type {
MouseDown,
MouseUp,
MouseMove,
MouseWheel,
DoubleClick,
};
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
MouseEvent clone_without_chrome_data() const;
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
Type type;
Web::DevicePixelPoint position;
Web::DevicePixelPoint screen_position;
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
UIEvents::MouseButton button { UIEvents::MouseButton::None };
UIEvents::MouseButton buttons { UIEvents::MouseButton::None };
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
UIEvents::KeyModifier modifiers { UIEvents::KeyModifier::Mod_None };
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
int wheel_delta_x { 0 };
int wheel_delta_y { 0 };
OwnPtr<ChromeInputData> chrome_data;
};
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
struct DragEvent {
enum class Type {
DragStart,
DragMove,
DragEnd,
Drop,
};
DragEvent clone_without_chrome_data() const;
Type type;
Web::DevicePixelPoint position;
Web::DevicePixelPoint screen_position;
UIEvents::MouseButton button { UIEvents::MouseButton::None };
UIEvents::MouseButton buttons { UIEvents::MouseButton::None };
UIEvents::KeyModifier modifiers { UIEvents::KeyModifier::Mod_None };
Vector<HTML::SelectedFile> files;
OwnPtr<ChromeInputData> chrome_data;
};
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
using InputEvent = Variant<KeyEvent, MouseEvent>;
}
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
namespace IPC {
template<>
ErrorOr<void> encode(Encoder&, Web::KeyEvent const&);
template<>
ErrorOr<Web::KeyEvent> decode(Decoder&);
template<>
ErrorOr<void> encode(Encoder&, Web::MouseEvent const&);
template<>
ErrorOr<Web::MouseEvent> decode(Decoder&);
}
Reference in a new issue Copy permalink