When a window containing a WebView becomes visibile, we have to inform
WebContent. This was only implemented for the Tab class (not Inspector
or Task Manaager).
This patch adds LadybirdWebViewWindow to contain the bare minimum needed
to render a LadybirdWebView. All windows containing a WebView inherit
from this class, to ensure their WebContent processes know they became
visible.
It's currently possible for window size/position updates to hang, as the
underlying IPCs are synchronous. This updates the WebDriver endpoint to
be async, to unblock the WebContent process while the update is ongoing.
The UI process is now responsible for informing WebContent when the
update is complete.
Window origins in AppKit are the bottom-left position of the NSWindow,
relative to the bottom-left of the screen. So we must do some alignment
of the top-left position received from WebDriver.
We call ns_event_to_key_event for the NSFlagsChanged event as well. By
retrieving the isARepeat flag on those events, we are guaranteed to
throw an exception.
See:
https://developer.apple.com/documentation/appkit/nsevent/1528049-arepeat?language=objc
Raises an NSInternalInconsistencyException if sent to an
NSFlagsChanged event or other non-key event.
When a platform key press or release event is repeated, we now pass
along a `repeat` flag to indicate that auto-repeating is happening. This
flag eventually ends up in `KeyboardEvent.repeat`.
On the view-source page, generate anchor tags for any 'href' or 'src'
attribute value we come across. This handles both when the attribute
contains an absolute URL and a URL relative to the page.
This requires sending the document's base URL over IPC to resolve
relative URLs.
Our handling of left vs. right modifiers keys (shift, ctrl, etc.) was
largely not to spec. This patch adds explicit UIEvents::KeyCode values
for these keys, and updates the UI to match native key events to these
keys (as best as we are able).
If the user only presses the shift key, for example, we are required to
still send that event to WebContent and generate the corresponding JS
events. Unfortunately, NSApp does not inform us of these events via the
keyDown/keyUp methods. We have to implement the flagsChanged interface,
and track for ourselves what modifier keys were pressed or released.
This has been implemented in Qt for quite some time. This patch adds the
same feature to AppKit. This is needed to run many WPT subtests with the
AppKit chrome. This is also needed to handle window.open, target=_blank
link clicks, etc.
This is overriding the URL passed to e.g. window.open and link clicks on
an <a target=_blank> element.
Note: This alone is not enough to support such use cases. We will also
need to actually implement opening child web views. But getting this fix
out of the way first makes that patch a bit simpler.
The main motivator here was noticing that --disable-sql-database did not
work with AppKit. Rather than re-implementing this there, move ownership
of these classes to WebView::Application, so that each UI does not need
to individually worry about it.
AppKit uses Private Use Area code points for a large collection of
functional keys (arrows, home/end, etc.). Re-assign them to 0 to avoid
tripping up WebContent's key handler.
Before this change, we were passing CGColorSpaceCreateDeviceRGB() to
CGImageCreate(), causing the system to assume that the image data is
in a device-specific RGB space without any color profile adjustments.
If your monitor is more vibrant than the assumed profile (for example,
a wide-gamut display), colors may appear over-saturated as there's no
correction applied for how the display actually renders those colors.
We now pass CGColorSpaceCreateWithName(kCGColorSpaceSRGB) instead,
which makes colors look the same in Ladybird as in other browsers. :^)
This forwards all drag-and-drop events from the UI to the WebContent
process. If the page accepts the events, the UI does not handle them.
Otherwise, we will open the dropped files as file:// URLs.
Currently, if we want to add a new e.g. WebContent command line option,
we have to add it to all of Qt, AppKit, and headless-browser. (Or worse,
we only add it to one of these, and we have feature disparity).
To prevent this, this moves command line flags to WebView::Application.
The flags are assigned to ChromeOptions and WebContentOptions structs.
Each chrome can still add its platform-specific options; for example,
the Qt chrome has a flag to enable Qt networking.
There should be no behavior change here, other than that AppKit will now
support command line flags that were previously only supported by Qt.
This call is used to inform the chrome that it should display a tooltip
now and avoid any hovering timers. This is used by <video> tags to
display the volume percentage when it is changed.
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.
By Setting setBordered propperty on header buttons to `Yes` this
path makes the whole button clickable. Previously the only the
icon was clickable, now it's easy to click.
This large commit also refactors LibWebView's process handling to use
a top-level Application class that uses a new WebView::Process class to
encapsulate the IPC-centric nature of each helper process.
In the upcoming changes, Skia painter will be switched to Metal backend,
so we can no longer assume `pitch = width * 4` while reading Gfx::Bitmap
that wraps IOSurface populated by writing into MTLTexture that has
padded scanlines.
This adds a motion preference to the browser UI similar to the existing
ones for color scheme and contrast.
Both AppKit UI and Qt UI has this new preference.
The auto value is currently the same as NoPreference, follow-ups can
address wiring that up to the actual preference for the OS.
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().
This was no longer doing anything. We'll eventually want a way to pass
system default fonts to each WebContent process, but we don't need to
squeeze everything through this API that was really meant for Serenity's
very idiosyncratic font system.
