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.
We can get away with using the forward declaration of EditEventHandler
in the header file (and avoid ~1k rebuilt files when EditEventHandler is
modified).
There will be an upcoming DragAndDropEventHandler class, so this patch
just sets things up so that the edit and drag-and-drop event handlers
are stored the same way in EventHandler.
This change causes the viewport to be treated as a "scroll frame,"
similar to how it already works for boxes with "overflow: scroll."
This means that, instead of encoding the viewport translation into a
display list, the items will be assigned the scroll frame id of the
viewport and then shifted by the scroll offset before execution. In the
future it will allow us to reuse a display list for repainting if only
scroll offset has changed.
As a side effect, it also removes the need for special handling of
"position: fixed" because compensating for the viewport offset while
painting or hit-testing is no longer necessary. Instead, anything
contained within a "position: fixed" element is simply not assigned
a scroll frame id, which means it is not shifted by the scroll offset.
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.
The spec does not define activation behavior of ctrl/cmd clicks, so we
have to go a bit ad-hoc here. When an anchor element is clicked with the
cmd (on macOS) or ctrl (on other platforms) modifier pressed, we will
skip activation of that element and pass the event on to the chrome. We
still dispatch the event to allow scripts to cancel the event.
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.
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.
This implements most of the CloseWatcher API from the html spec.
AbortSignal support is unimplemented.
Integration with dialogs and popovers is also unimplemented.
This now matches the behavior of did_request_link_context_menu and
friends. Previously the coordinates relative to the page rather than
viewport were sent to the chrome.
The main intention of this change is to have a consistent look and
behavior across all scrollbars, including elements with
`overflow: scroll` and `overflow: auto`, iframes, and a page.
Before:
- Page's scrollbar is painted by Browser (Qt/AppKit) using the
corresponding UI framework style,
- Both WebContent and Browser know the scroll position offset.
- WebContent uses did_request_scroll_to() IPC call to send updates.
- Browser uses set_viewport_rect() to send updates.
After:
- Page's scrollbar is painted on WebContent side using the same style as
currently used for elements with `overflow: scroll` and
`overflow: auto`. A nice side effects: scrollbars are now painted for
iframes, and page's scrollbar respects scrollbar-width CSS property.
- Only WebContent knows scroll position offset.
- did_request_scroll_to() is no longer used.
- set_viewport_rect() is changed to set_viewport_size().
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.
Every single client of this function was immediately calling paintable()
on the result anyway, so there was no need to return a layout node!
This automatically leverages the cached containing block pointer we
already have in Paintable, which melts away a bunch of unnecessary
traversal in hit testing and painting. :^)
Change `EventHandler::handle_keydown()` to no longer assume the cursor
position's node is always a `DOM::Text`. While this assumption holds
for `HTMLInputElement` that has a shadow DOM with a text node, an empty
`contenteditable` might not have any children. With this change,
`handle_keydown()` creates a new text node if the cursor position's
node is not a text node.
Fixes a crash that occurs when inputting into an empty contenteditable
element (`EditEventHandler::handle_delete()` assumes the cursor
position's node is always `DOM::Text`, which is not the case for an
empty `contenteditable`).
`EventHandler::handle_keyup()` and `EventHandler::handle_keydown()`
return true if the event has been handled and false otherwise. This is
the opposite behavior to `EventHandler::fire_keyboard_event()`.
This change inverts the return value from `fire_keyboard_event` in
these methods, allowing shortcut keys to be propagated to the Serenity
Browser UI as expected.
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).
With this change, clicking on an editable element, such as an `input`
or `textarea` causes the cursor position to be updated to the current
mouse position.
With this change, chrome no longer has to ask the WebContent process
to paint the next frame into a specified bitmap. Instead, it allocates
bitmaps and sends them to WebContent, which then lets chrome know when
the painting is done.
This work is a preparation to move the execution of painting commands
into a separate thread. Now, it is much easier to start working on the
next frame while the current one is still rendering. This is because
WebContent does not have to inform chrome that the current frame is
ready before it can request the next frame.
Additionally, as a side bonus, we can now eliminate the
did_invalidate_content_rect and did_change_selection IPC calls. These
were used solely for the purpose of informing chrome that it needed to
request a repaint.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
This fixes an elusive issue where changing the hovered node would cause
a JS event handler to run, changing the shape of the paint tree before
we had a chance to get the cursor.
A more robust fix here will be to let paintables own their used/computed
values (so they don't have to look into the layout tree for them) but
that's a much bigger change.
We need to give pages the opportunity to intercept keydown events and
potentially stop them from propagating. Otherwise, for example, pressing
an arrow key in an <input> element is not observable via script.
The return value of fire_keyboard_event is meant to indicate whether the
event should continue propagating (true) or halt (false). This exactly
matches the return value of dispatch_event, so by negating the result,
we are propagating events we shouldn't, and not propagating events we
should.
