This closes the window at WebContent process startup where we were
relying on Gfx::FontDatabase having some resolvable value in its default
font query.
This option skips attempting any chrome IPC which even with the
`--new-window` does not open a new browser process. This is annoying
when trying to compare browser options as opening a new window with
the currently running chrome ignores any options passed to the new
ladybird invocation.
This adds a `--experimental-cpu-transforms` option to Ladybird and
WebContent (which defaults to false/off).
When enabled the AffineCommandExecutorCPU will be used to handle
painting transformed stacking contexts (i.e. stacking contexts where
the transform is something other than a simple translation). The regular
command executor will still handle the non-transformed cases.
This is hidden under a flag as the `AffineCommandExecutorCPU` is very
incomplete now. It missing support for clipping, text, and other basic
commands. Once most common commands have been implemented this flag
will be removed.
LibWeb will need to use unbuffered requests to support server-sent
events. Connection for such events remain open and the remote end sends
data as HTTP bodies at its leisure. The browser needs to be able to
handle this data as it arrives, as the request essentially never
finishes.
To support this, this make Protocol::Request operate in one of two
modes: buffered or unbuffered. The existing mechanism for setting up a
buffered request was a bit awkward; you had to set specific callbacks,
but be sure not to set some others, and then set a flag. The new
mechanism is to set the mode and the callbacks that the mode needs in
one API.
This is to avoid including any LibProtocol header in Objective-C source
files, which will cause a conflict between the Protocol namespace and a
@Protocol interface.
See Ladybird/AppKit/Application/ApplicationBridge.cpp for why this
conflict unfortunately cannot be worked around.
Previously RS handled all the requests in an event loop, leading to
issues with connections being started in the middle of other connections
being started (and potentially blowing up the stack), ultimately causing
requests to be delayed because of other requests.
This commit reworks the way we handle these (specifically starting
connections) by first serialising the requests, and then performing them
in multiple threads concurrently; which yields a significant loading
performance and reliability increase.
Now that the chrome process is a singleton on all platforms, we can
safely add a cache to the CookieJar to greatly speed up access. The way
this works is we read all cookies upfront from the database. As cookies
are updated by the web, we store a list of "dirty" cookies that need to
be flushed to the database. We do that synchronization every 30 seconds
and at shutdown.
There's plenty of room for improvement here, some of which is marked
with FIXMEs in the CookieJar.
Before these changes, in a SQL database populated with 300 cookies,
browsing to https://twinings.co.uk/ WebContent spent:
19,806ms waiting for a get-cookie response
505ms waiting for a set-cookie response
With these changes, it spends:
24ms waiting for a get-cookie response
15ms waiting for a set-cookie response
We already have required this version for quite a while for Lagom,
Ladybird and Serenity. Now that we require it in all of our CMakeLists,
let's scrub for better ways of writing things.
This actually actives the underlying tab if needed. This wasn't an issue
previously, as new tabs were always created in already active windows.
But when new windows/tabs are requested from new Ladybird processes, we
need to actually activate those tabs.
For some reason, we occasionally receive a junk `info` pointer from the
CFSocketCallback we create for socket notifiers. Instead of capturing a
pointer to the local Core::Notifier for this `info` member, grab it from
the thread data instance based on the socket FD.
This was mostly seen when spamming new window requests to an existing
Ladybird process.
When we receive a LibCore event, we post an "application defined" Cocoa
event to the NSApp. However, we are currently only processing these from
`pump`, which is only invoked manually.
Instead, we should listen for the event that we've posted and process
the event queue at that time. This is much closer to how Qt's event loop
behaves as well with EventLoopImplementationQtEventTarget.
This shows the following actions:
* Reload Tab
* Duplicate Tab
* Move Tab
* Move to Start
* Move to End
* Close Tab
* Close Other Tabs
* Close Tabs to Left
* Close Tabs to Right
* Close Other Tabs
Rather than getting the tab name from the tab container. This resolves
an issue where ampersands were being introduced to the window title
when changing tabs.
This broke due to the way we now use posix_spawn under the hood. This
moves the handling of the callgrind option to the launcher helper where
we iterate over the candidate process paths, as we need to augment the
way we fork the process for callgrind based on those paths.
This also opens the door for running other processes under callgrind in
the future.
