mirrors/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-24 18:24:45 -05:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Page/DragAndDropEventHandler.h

69 lines
2.8 KiB
C
Raw Normal View History

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
/*
* Copyright (c) 2024, Tim Flynn <trflynn89@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <LibJS/Heap/Cell.h>
#include <LibJS/Heap/GCPtr.h>
#include <LibWeb/Forward.h>
#include <LibWeb/HTML/DragDataStore.h>
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
#include <LibWeb/Page/EventResult.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/PixelUnits.h>
namespace Web {
class DragAndDropEventHandler {
public:
void visit_edges(JS::Cell::Visitor& visitor) const;
LibWeb: Make the drag data store reference counted Ownership of the drag data store is a bit weird. In a normal drag-and- drop operation, the DragAndDropEventHandler owns the store. When events are fired for the operation, the DataTransfer object assigned to those events are "associated" with the store. We currently represent that with an Optional<DragDataStore&>. However, it's also possible to create DataTransfer objects from scripts. Those objects create their own drag data store. This puts DataTransfer in a weird situation where it may own a store or just reference one. Rather than coming up with something like Variant<DDS, DDS&> or using MaybeOwned<DDS> here, we can get by with just making the store reference counted.
2024-08-21 06:39:02 -04:00
bool has_ongoing_drag_and_drop_operation() const { return !m_drag_data_store.is_null(); }
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+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 handle_drag_start(JS::Realm&, CSSPixelPoint screen_position, CSSPixelPoint page_offset, CSSPixelPoint client_offset, CSSPixelPoint offset, unsigned button, unsigned buttons, unsigned modifiers, Vector<HTML::SelectedFile> files);
EventResult handle_drag_move(JS::Realm&, JS::NonnullGCPtr<DOM::Document>, JS::NonnullGCPtr<DOM::Node>, CSSPixelPoint screen_position, CSSPixelPoint page_offset, CSSPixelPoint client_offset, CSSPixelPoint offset, unsigned button, unsigned buttons, unsigned modifiers);
EventResult handle_drag_leave(JS::Realm&, CSSPixelPoint screen_position, CSSPixelPoint page_offset, CSSPixelPoint client_offset, CSSPixelPoint offset, unsigned button, unsigned buttons, unsigned modifiers);
EventResult handle_drop(JS::Realm&, CSSPixelPoint screen_position, CSSPixelPoint page_offset, CSSPixelPoint client_offset, CSSPixelPoint offset, unsigned button, unsigned buttons, unsigned 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
private:
enum class Cancelled {
No,
Yes,
};
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 handle_drag_end(JS::Realm&, Cancelled, CSSPixelPoint screen_position, CSSPixelPoint page_offset, CSSPixelPoint client_offset, CSSPixelPoint offset, unsigned button, unsigned buttons, unsigned 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
JS::NonnullGCPtr<HTML::DragEvent> fire_a_drag_and_drop_event(
JS::Realm&,
JS::GCPtr<DOM::EventTarget> target,
FlyString const& name,
CSSPixelPoint screen_position,
CSSPixelPoint page_offset,
CSSPixelPoint client_offset,
CSSPixelPoint offset,
unsigned button,
unsigned buttons,
unsigned modifiers,
JS::GCPtr<DOM::EventTarget> related_target = nullptr);
bool allow_text_drop(JS::NonnullGCPtr<DOM::Node>) const;
void reset();
LibWeb: Make the drag data store reference counted Ownership of the drag data store is a bit weird. In a normal drag-and- drop operation, the DragAndDropEventHandler owns the store. When events are fired for the operation, the DataTransfer object assigned to those events are "associated" with the store. We currently represent that with an Optional<DragDataStore&>. However, it's also possible to create DataTransfer objects from scripts. Those objects create their own drag data store. This puts DataTransfer in a weird situation where it may own a store or just reference one. Rather than coming up with something like Variant<DDS, DDS&> or using MaybeOwned<DDS> here, we can get by with just making the store reference counted.
2024-08-21 06:39:02 -04:00
RefPtr<HTML::DragDataStore> m_drag_data_store;
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
// https://html.spec.whatwg.org/multipage/dnd.html#source-node
JS::GCPtr<DOM::EventTarget> m_source_node;
// https://html.spec.whatwg.org/multipage/dnd.html#immediate-user-selection
JS::GCPtr<DOM::Node> m_immediate_user_selection;
// https://html.spec.whatwg.org/multipage/dnd.html#current-target-element
JS::GCPtr<DOM::Node> m_current_target_element;
// https://html.spec.whatwg.org/multipage/dnd.html#current-drag-operation
FlyString m_current_drag_operation;
};
}
Reference in a new issue Copy permalink