Use the LibWebView history mirror to preserve traversable session
history across WebContent process swaps. WebContent reports snapshots to
the UI process, and new renderers can be seeded from the mirror.
Browser back and forward now resolve through the UI-owned used history
steps. WebContent still runs the spec traversal path when the current
renderer has enough matching state to do so.
Handle canceled and no-op UI navigations without leaving speculative
history entries or pending WebDriver waits behind. Preserve traversal
precheck state across synchronous IPC shutdown, and avoid overwriting a
restored target entry's persisted scroll state before the document has
adopted that entry.
Use a native QVulkanWindow child for Linux DMABUF presentation instead
of making WebContentView itself a QRhiWidget. This keeps BrowserWindow
on Qt's normal QWidget backing store path while sampling compositor
DMABUF backing stores directly in Vulkan.
Keep WebContentView's paintEvent as fallback for builds without Vulkan
DMABUF support and for cases where the Vulkan instance or window cannot
be created. Set an explicit Vulkan API version before creating the
shared QVulkanInstance so validation layers do not reject Qt defaults.
Show a delayed preview popup when hovering background tabs. Build the
thumbnail from the cached front or backup WebContent bitmap so chrome
does not need a fresh screenshot request or WebContent repaint on hover.
Tie the popup to the tab hover lifecycle and hide it on current-tab
hovers, tab presses, drags, layout changes, and tab strip exits.
Track whether a keydown should perform text insertion separately from
the delivered code point. Native frontends and text-oriented test paths
can now mark events that came from text input, while shortcut-style key
events keep Alt-modified default insertion suppressed.
This lets macOS Option-generated text such as Option+A and Option+Space
insert into editable controls without making plain Alt shortcuts insert
their base character. Add coverage for Alt text, Ctrl+Alt text,
separator text, Ctrl-only shortcuts, and Alt shortcuts.
Stop forcing RHI for every QWidget on macOS. The web content view is
the only widget that needs Metal, and QRhiWidget already requests that.
Make the web content view a native child before parenting it into the
tab UI so Qt does not propagate its RHI config to the browser window
backing store. This keeps chrome repaints on the normal Cocoa backing
store path instead of copying the full window backing store into a
texture.
Support Command+Shift+[ and Command+Shift+] for moving between
Qt tabs on macOS. Also support the physical Control+Tab and
Control+Shift+Tab shortcuts accepted by other browsers.
Treat these as browser-reserved shortcuts so WebContent does not
consume the shortcut override before the browser action can run.
Qt swaps Command into ControlModifier and Control into MetaModifier on
macOS so shortcut definitions can stay portable. Convert those modifiers
back to Web-facing semantics before sending input events to LibWeb.
This lets Command-click behave as platform-control click instead of
being mistaken for Control-click, while physical Control-click still
opens the context menu on macOS.
Platform wheel deltas describe movement in the view, not in page CSS
pixels. Convert them by page zoom before dispatch so physical scrolling
covers a smaller page area when zoomed in.
Do this before the UI-side async scrolling shortcut so compositor
scrolling and main-thread fallback scrolling use the same delta. Also
avoid applying the Qt device pixel ratio while converting angle-only
wheel input, since LibWeb later handles device-pixel scaling itself.
Translate Qt native zoom gestures into Web::PinchEvent for the web
content view. This gives the Qt UI the same pinch-to-zoom input path as
the AppKit UI while leaving ordinary wheel scrolling unchanged.
Map the Qt native gesture screen position back into WebContentView
before creating the event, since macOS delivers the gesture through the
top-level widget window after forwarding. Keeping the pinch focal point
in content coordinates lets visual viewport zoom preserve the user's
focus point.
Use QRhiWidget for the Qt web content view on macOS and render the
current IOSurface-backed shared image into the widget's Metal render
target. This keeps normal presentation on the GPU instead of painting a
QImage wrapper over the shared bitmap.
Force Qt Widgets' RHI backing store to Metal before QApplication is
created so QRhiWidget can obtain the top-level QRhi even when the native
window is created before the web content widget enters the hierarchy.
Other platforms keep the existing QWidget and QPainter path.
Let Ctrl+L bypass WebContent in the shortcut override path so the
browser chrome can focus the location editor immediately. This matches
Qt's other browser-owned tab and window shortcuts.
Picker input starts in each platform UI, while protocol state lives in
LibWebView. Route movement, primary clicks, Escape, and leave events
through the WebView picker API so each frontend drives the same hit-test
and picker-event path.
The selected click is consumed because picker mode uses it to choose an
element for DevTools rather than activate page content.
AppKit routes normal mouse input through WebViewBridge, which converts
view points to device pixels before forwarding to LibWeb. Picker input
bypasses that enqueue path, so apply the same scaling before requesting
a picker hit test.
WebContentView scales its painter into device-pixel coordinates before
painting page bitmaps. When no page bitmap was available, the fallback
fill still used the widget rect in CSS pixels. On high-DPI displays, it
only filled the top-left portion of the viewport.
Use the stored device-pixel viewport size for the no-bitmap fill and for
the fallback area around a smaller bitmap.
The browser process forwards the maximum frame rate to WebContent, but
the compositor process had no copy of that display timing metadata or
the display identity needed by compositor-local vsync.
Add one compositor control IPC message carrying the optional display ID
and refresh rate together, and store both values on each compositor
context.
Seed the page background fallback from the platform color scheme before
WebContent has painted. Update the same fallback when the platform theme
changes, and when the preferred color scheme is forced through the debug
menu, so unpainted web view areas use the matching Canvas color.
Let browser chrome shortcuts for tab and window management bypass the
WebContent shortcut override path. This makes new tab, new window,
reopen closed tab, tab switching, close tab, and quit dispatch through
Qt immediately instead of waiting for page event handling.
Track whether WebContent still needs a beforeunload check and let the
frontends immediately remove a tab or window when no prompt can be
shown. WebContent still receives the close request so pagehide, unload,
and cleanup steps can run.
When the visible view is removed immediately, keep detached ownership of
the WebContent page until it reports that the top-level traversable
closed. If no acknowledgement arrives, release detached ownership and
ask ProcessManager to shut down the unused WebContent process.
Refresh Qt chrome palettes from the current color scheme when the
application palette changes. Recompute autocomplete and location field
colors and repaint WebContent immediately so theme changes do not
require another interaction or restart.
Notify the UI process with the solid canvas background color recorded
for the top-level document. This is the Canvas system color with the
effective document background composited over it, matching the color
used before normal painting.
Store that color on the view and use it when AppKit, Qt, and Gtk need
to fill areas exposed while an older bitmap is still on screen during a
window resize.
This factory is only used by the UI. An upcoming commit will make it
depend on LibFileSystem. LibWeb currently does not link LibFileSystem,
and doing so would push LibWeb in the wrong direction (we should be
doing less file IO in LibWeb, not more).
Wheel deltas were truncated to int at the platform input boundary,
which dropped the sub-pixel tail of trackpad momentum scrolls. Each
NSEvent's scrollingDeltaY arrived as a CGFloat, got cast to int, and
flowed through IPC, EventHandler, and PaintableBox::scroll_by as int,
losing fractional information that never came back.
Widen Web::MouseEvent::wheel_delta_{x,y} to double and propagate
through Page, EventHandler, Paintable, PaintableBox, and the AppKit,
Qt, and GTK input paths.
Other engines converge on roughly 40 pixels per line as the per-line
step for discrete mouse wheel input (Chrome's kWheelDelta of 120 over
3 lines, WebKit's Scrollbar::pixelsPerLineStep of 40, Chrome's macOS
kScrollbarPixelsPerCocoaTick of 40). At a step of 24 we were scrolling
about 60% as far per tick as Chrome on the same input, which made the
browser feel sluggish under a regular wheel.
Bumping the constant to 40 in the Qt, Gtk, and AppKit frontends puts
us at 120 pixels per discrete tick on Linux (3 lines * 40 pixels) and
aligns the macOS imprecise-scroll multiplier with WebKit and Chrome.
High-precision (trackpad) input is unaffected on all platforms, since
those paths use pixel deltas directly without applying a multiplier.
Generalize the backing store sharing abstraction into SharedImage, which
represents shared GPU memory independently of Skia and can be used to
share memory between different processes or different GPU contexts.
This moves normal/double/triple click checking into WebContent, the
client only has to send a click count in order to activate a double
or triple click in the content. This means that the AppKit UI will no
longer fire multiple double clicks when clicking in place more than 3
times. This matches the behavior of other browsers on macOS.
We will now also fire the click event regardless of whether a dblclick
event will follow, as the spec requires.
The set_viewport_size and set_device_pixel_ratio IPC messages were sent
separately, potentially causing a race condition when the DPR changes
(e.g. moving a window between screens): the DPR message would arrive
and use a stale viewport size, computing a temporarily wrong CSS
viewport. Combine both into a single set_viewport IPC that updates the
device viewport size and DPR together.
When triple clicking on text, we should select the entire paragraph, or
entire line in <input>s and <textarea>s. If the mouse button is held
down and the user starts dragging, the selection expands with additional
paragraphs or lines.
This expands on the work of Kai Wildberger (PR #7681) but was adjusted
for the work that happened previously to support double click + drag
moves and includes triple click support for our Qt UI.
Co-authored-by: Kai Wildberger <kiawildberger@gmail.com>
The `Bitmap` type was referring to to its internal pixel format by a
name that represents the order of the color components as they are layed
out in memory. Contrary, the `Color` type was using a naming that where
the name represents the order of the components from most to least
significant byte when viewed as a unsigned 32bit integer. This is
confusing as you have to keep remembering which mental model to use
depending on which code you work with.
To unify the two, the naming of RGBA-like colors in the `Color` type has
been adjusted to match the one from the Bitmap type. This seems to be
generally in line with how web APIs think about these types:
* `ImageData.pixelFormat` can be `rgba-8unorm` backed by a
`Uint8ClamedArray`, but there is no pixel format backed by a 32bit
unsigned type.
* WebGL can use format `RGBA` with type `UNSIGNED_BYTE`, but there is no
such format with type `UNSIGNED_INT`.
Additionally, it appears that other browsers and browser-adjacent
libraries also think similarly about these types:
* Firefox:
https://github.com/mozilla-firefox/firefox/blob/main/gfx/2d/Types.h
* WebKit:
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/graphics/PixelFormat.h
* Skia:
https://chromium.googlesource.com/skia/+/refs/heads/main/include/core/SkColorType.h
This has the not so nice side effect that APIs that interact with these
types through 32bit unsigned integers now have the component order
inverted due to little-endian byte order. E.g. specifying a color as hex
constant needs to be done as `0xAABBGGRR` if it is to be treated as
RGBA8888.
We could alleviate this by providing endian-independent APIs to callers.
But I suspect long-term we might want to think differently about bitmap
data anyway, e.g. to better support HDR in the future. However, such
changes would be more involved than just unifying the naming as done
here. So I considered that out of scope for now.
The faux position we created here is adjusted by the device pixel ratio
later on, which would invoke integer overflow on screens with a DPR
greater than 1.
Instead of creating special data for a mouse move event, let's just add
an explicit leave event handler.
Previously, when the mouse left the WebView, the currently hovered node
would remain hovered (including the scroll bar). This felt a bit awkward
and is not how other browsers behave.
The select dropdown was doing its own ad-hoc method of handling DPR. We
now handle it just like other context menus. Previously, the drop down
in the AppKit chrome was twice as large as it should be.
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.
m_hover_label did not have checks if the mouse is in the same location.
This caused clickable URLs to be hidden.
Also shortened the label text to not be longer than half of the window.
LibWebView now knows how to launch RequestServer and ImageDecoderServer
without help from the UI, so let's move ownership of these services over
to LibWebView for de-duplication.
We will want to re-inform WebContent of the system visibility state when
we create a new process after a crash. This changes the IPC to just send
the enum value directly, instead of a boolean, so that we can just store
that enum value directly on the ViewImplementation class.
