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.
Not only does this match the spec, but otherwise when the UI process
sends us the initial visibility update, we would ignore the message as
we believed we were already visible (thus the update would not reach the
document).
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.
On macOS, this is resulting in values of window.screenX, window.screenY,
window.outerWidth and window.outerHeight that are 2x larger than Safari,
Firefox, and our AppKit UI.
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.
And here's the wild part: instead of cloning WPT tests, import the
relevant WPT tests that this fixes into our own test suite.
This works by adding a small Ladybird-specific callback in
resources/testharnessreport.js (which is what that file is meant for!)
Note that these run as text tests, and so they must signal the runner
when they are done. Tests using the "usual" WPT harness should just
work, but tests that do something more freestyle will need manual
signaling if they are to be imported.
I've also increased the test timeout here from 30 to 60 seconds,
to accommodate the larger WPT-style tests.
Invoking exec() entirely blocks the UI application's main thread. Qt
explicitly recommends against this. In practice, it seems prevents some
IPC messages from being handled by the UI until the dialog is closed by
the user.
Instead, use open() (which is non-blocking) and set up a signal handler
to deal with the result.
It is easy to forget to set this flag on macOS, where doing so causes
many tests to fail. So let's just set it via code along with other
options to make it a bit more foolproof.
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.
This abstraction will help us to support multiple IPC transport
mechanisms going forward. For now, we only have a TransportSocket that
implements the same behavior we previously had, using Unix Sockets for
IPC.
Ladybird's HelperProcess.cpp was the only user of the IPCProcess class.
Moving the helper class from LibCore allows for some more interesting
LibIPC changes in the upcoming commits.
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`.
We previously only supported enabling headless mode on a per-session
basis via the capabilities record. We don't have the ability to mutate
this record from WPT, so this adds a flag to set the default mode.
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.
This will be the first step is making better use of system libraries
like fontconfig and CoreText to load system fonts for use by the UI
process and the CSS style computer.
Useful for finding tests that take a long time to execute.
As of this commit, on macOS, we have:
Text/input/cookie.html: 1228ms
Text/input/css/transition-basics.html: 1060ms
Text/input/HTML/DedicatedWorkerGlobalScope-instanceof.html: 182ms
Text/input/WebAnimations/misc/animation-events-basic.html: 148ms
Text/input/Crypto/SubtleCrypto-deriveBits.html: 130ms
Text/input/IntersectionObserver/observe-box-inside-container-with-scrollable-overflow.html: 117ms
Text/input/navigation/attempt-navigating-object-without-a-document.html: 109ms
Text/input/css/getComputedStyle-print-all.html: 71ms
Text/input/WebAnimations/misc/animation-single-iteration-no-repeat.html: 61ms
Text/input/WebAnimations/animation-methods/updatePlaybackRate.html: 55ms
And on Linux:
Text/input/cookie.html: 1326ms
Text/input/css/transition-basics.html: 1155ms
Screenshot/text-shadow.html: 772ms
Screenshot/css-background-repeat.html: 622ms
Screenshot/object-fit-position.html: 541ms
Screenshot/css-background-position.html: 456ms
Screenshot/css-gradients.html: 451ms
Screenshot/border-radius.html: 400ms
Screenshot/svg-radialGradient.html: 398ms
Text/input/css/getComputedStyle-print-all.html: 325ms
The headless-browser source is getting a bit unwieldy. The ordering of
class and method definitions is fragile; e.g. the application and web
view classes each require full definitions of each other. So it has
reached the point where it makes sense to give headless-browser some
better file structure.
To prepare for that, this patch simply moves its source to live along-
side the other browser chromes. This location is a bit better prepared
for creating more files, as the Utilities folder doesn't even have its
own CMakeLists.txt.
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.
These were used to provide a layer of abstraction between ResourceLoader
and the networking backend. Now that we only have RequestServer, we can
remove these adapters to make the code a bit easier to follow.
Now that we use libcurl, there's no reason to keep Qt networking around.
Further, it doesn't support all features we need anyways, such as non-
buffered request handling for SSE.
We don't create a ChromeProcess in headless-browser, so it is currently
not increasing it's open file limit. This is causing crashes on macOS,
which has a very low default limit.
We are currently creating a signal socket and socket notifier before the
Qt event loop itself has been created. Thus, when we receive a signal,
we are not actually notified when we write that signal number to the
signal socket.
This was also the source of the following error message being displayed
on every launch of the browser:
QSocketNotifier: Can only be used with threads started with QThread
