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.
This really only affects headless-browser when it is linked with Qt. In
that case, it currently uses Qt networking by default and does not have
a flag to use RequestServer instead. Change the default to use RS so it
can undergo sanitized testing in CI.
The following command was used to clang-format these files:
clang-format-18 -i $(find . \
-not \( -path "./\.*" -prune \) \
-not \( -path "./Base/*" -prune \) \
-not \( -path "./Build/*" -prune \) \
-not \( -path "./Toolchain/*" -prune \) \
-not \( -path "./Ports/*" -prune \) \
-type f -name "*.cpp" -o -name "*.mm" -o -name "*.h")
There are a couple of weird cases where clang-format now thinks that a
pointer access in an initializer list, e.g. `m_member(ptr->foo)`, is a
lambda return statement, and it puts spaces around the `->`.
Previously the 'device independent pixels' (which consider scaling)
were used, and then scaling would be applied again when calculating the
screen width for CSS.
It previously resided in LibWebView to hide the details of launching a
singleton process. That functionality now lives in LibCore. By moving
this to Ladybird, we will be able to register the process with the task
manager.
This will be needed to collect statistics from processes that do not
have anything to do with LibWebView. The ProcessInfo structure must be
virtual to allow callers to add application-specific information.
Sometimes I like to play around with running Ladybird tests using full
blown Ladybird instead of just headless browser to interactively mess
around with the test page. One problem with this is that the internals
object is not exposed in this mode.
This commit supports this usecase by adding an option to specifically
expose the internals object without needing to run headless-browser
in test mode.
When launched with the new --enable-idl-tracing option, we now log
every call to web platform APIs declared via IDL, along with the
arguments passed.
This can be very helpful when trying to figure out what a site is
doing, especially if it's not doing what you'd expect.
When running with --log-all-js-exceptions, we will print the message
and backtrace for every single JS exception that is thrown, not just
the ones nobody caught.
This can sometimes be very helpful in debugging sites that swallow
important exceptions.
Before this change we had to keep session history on browser side to
calculate a url for back/forward/reload action.
Now, with a mature enough implementation of navigation algorithms from
the specification, there is no need to use
history on the browser side to calculate navigation URLs because:
- Traversable navigable owns session history that is aware of all
navigations, including those initiated by History API and Navigation
API
- TraversableNavigable::traverse_the_history_by_delta() uses
traversable's history to calculate the next URL based on delta, so
there is no need for UI to keep sesion history.
In the future, we will likely want to add a way to pull session history
from WebContent to make it browsable from the UI.
