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 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.
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.
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.
The previous name was extremely misleading, because the call is used for
pushing or replacing new session history entry on chrome side instead of
only changing URL.
Currently the `<select>` dropdown IPC uses the option value attr to
find which option is selected. This won't work when options don't
have values or when multiple options have the same value. Also the
`SelectItem` contained so weird recursive structures that are
impossible to create with HTML. So I refactored `SelectItem` as a
variant, and gave the options a unique id. The id is send back to
`HTMLSelectElement` so it can find out exactly which option element
is selected.
We already display a speaker icon on tabs which are playing audio. This
allows the user to click that icon to mute the tab, at which point the
icon is replaced with a muted speaker icon.
We would previously hide the icon when audio stopped playing. We now do
this only if the tab isn't muted. If it is muted, the muted speaker icon
remains on the tab so that the page isn't stuck in a muted state.
When audio begins playing, add a button as an accessory view with a
speaker icon to indicate which tab is playing audio. This button is
currently disabled, but in the future may be used to mute the tab.
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
The AppKit chrome currently handles all input events before selectively
forwarding those events to WebContent. This means that WebContent does
not see events like cmd+c.
Here, we make use of LibWebView's input handling and wait for LibWebView
to inform the chrome that it should handle the event itself.
The IPC layer between chromes and LibWeb now understands that multiple
top level traversables can live in each WebContent process.
This largely mechanical change adds a billion page_id/page_index
arguments to make sure that pages that end up opening new WebViews
through mechanisms like window.open() still work properly with those
extra windows.
Instead of spawning these processes from the WebContent process, we now
create them in the Browser chrome.
Part 1/N of "all processes are owned by the chrome".
These IPCs are different than other IPCs in that we can't just set up a
callback function to be invoked when WebContent sends us the screenshot
data. There are multiple places that would set that callback, and they
would step on each other's toes.
Instead, the screenshot APIs on ViewImplementation now return a Promise
which callers can interact with to receive the screenshot (or an error).
With this change, chrome no longer has to ask the WebContent process
to paint the next frame into a specified bitmap. Instead, it allocates
bitmaps and sends them to WebContent, which then lets chrome know when
the painting is done.
This work is a preparation to move the execution of painting commands
into a separate thread. Now, it is much easier to start working on the
next frame while the current one is still rendering. This is because
WebContent does not have to inform chrome that the current frame is
ready before it can request the next frame.
Additionally, as a side bonus, we can now eliminate the
did_invalidate_content_rect and did_change_selection IPC calls. These
were used solely for the purpose of informing chrome that it needed to
request a repaint.
