Rather than set a hacky scale factor on our QIconEngine, just set the
icon size for the toolbar icons. This avoids the icons being
unnecessarily scaled in other places (i.e. the context menu).
Rather than render the icons to a 16x16 bitmap, keep them as vector
graphics and render them on request. This keeps the icons crisp on high
DPI displays.
In some places in the code QAction instances are added to a parent
directly on instantiation. In the case they are not, Valgrind
reports them as leaking.
Doing this removes the qt6-svg dependency and allows our rasterizer to
be used for these little icons (and happens to be a fair bit smaller
than the old SVGs).
The data we want to send out of the WebContent process is identical for
audio and video elements. Rather than just duplicating all of this for
audio, generalize the names used for this IPC for all media elements.
This also encapsulates that data into a struct. This makes adding new
fields to be sent much easier (such as an upcoming field for muting the
element).
The goal here is to reduce the amount of WebContent client APIs that are
duplicated across every ViewImplementation. Across our three browsers,
we currently:
Ladybird - Mix some AK::Function callbacks and Qt signals to notify
tabs of WebContent events.
Browser - Use only AK::Function callbacks.
headless-browser - Drop most events on the floor.
Instead, let's only use AK::Function callbacks across all three browsers
to propagate events to tabs. This allows us to invoke those callbacks
directly from LibWebView instead of all three browsers needing to define
a trivial `if (callback) callback();` override of a LibWebView virtual
function. For headless-browser, we can simply not set these callbacks.
As a first pass, this only converts WebContent events that are trivial
to this approach. That is, events that were simply passed onto the tab
or handled without much fuss.
This is to match Browser, where ownership of all "subwidgets" is placed
on the tab as well. This further lets us align the web view callbacks to
match Browser's OOPWV as well, which will later let us move them into
the base LibWebView class.
The implementations of handle_web_content_process_crash and
take_screenshot are exactly the same across Browser and Ladybird. Let's
reduce some code duplication and move them to LibWebView.
Previously, we were doing mapToGlobal() via the Tab widget, but the
widget position was actually relative to the WebContentView. This
meant context menus appeared slightly vertically offset from where
you clicked.
This commit adds the common actions you'd expect to the Ladybird context
menu, arranged like so:
┌──────────────────────────────┐
│ Go Back Alt+Left │
│ Go Forward Alt+Right │
│ Reload Ctrl+R │
│ ──────────────────────────── │
│ Copy Ctrl+C │
│ Select All Ctrl+A │
│ ──────────────────────────── │
│ View Source Ctrl+U │
│ Inspect Element │
└──────────────────────────────┘
We now load SVG icons (via the Qt resource system) and render them into
a QIcon (with normal and disabled variants) using system colors.
We also re-render them if the system color theme changes.
This instantly makes Ladybird look less foreign on my Linux box.
I drew the icons myself, and they could definitely be more optimized,
but this was my first time using Inkscape. :^)
This adds a -P option to run Ladybird under callgrind. It starts with
instrumentation disabled. To start capturing a profile (once Ladybird
has launched) run `callgrind_control -i on` and to stop it again run
`callgrind_control -i off`.
P.s. This is pretty much stolen from Andreas (and is based on the patch
everyone [that wants a profile] have been manually applying).
Previously when there was a very long url that spanned outside of the
address bar, the text shown would be the one starting from the very end
of the url instead of from the beginning, so you would be seeing the
query parameters for example, instead of the domain.
This allows us to use standard Serenity IPC infrastructure rather than
manually creating FD-passing sockets. This also lets us use Serenity's
WebDriver Session class, removing the copy previously used in Ladybird.
This ensures any changes to Session in the future will be picked up by
Ladybird for free.
We now replace the current history entry if the page-load has been
caused because of a redirect. This makes it able to traverse the
history if one of the entries redirects you, which previously
caused an infinite history traversion loop.
Depends on https://github.com/SerenityOS/serenity/pull/16004
The WebDriver will pass the --webdriver-fd-passing-socket command line
option when it launches Ladybird. Forward this flag onto the WebContent
process, where it will create the WebDriverConnection for IPC.
Previously, reloading went back to the first page loaded by
WebView::load() or WebView::load_html(), as they are the only methods
that modify m_url, which is what the reload loaded. Now we handle
reloads in Tab.cpp by simply loading the last entry in the m_history.
The hackish initial loading of about:blank was previously added to the
history, so you could go back to it (which wasn't very ergonomic). Now
we set the m_is_history_navigation flag before loading it so it doesn't
get added to the history.
Previously we were always pushing to history on the on_load_start
callback. Now we only do that if we are NOT navigating through the
history navigation (loading pages by going back/forward). This is what
the SerenityOS browser does:^)
We now emit a new signal for backward mouse button's mouseup and forward
mouse button's mouseup which is handled by going back and forward in the
history respectively:))
There are no custom changes for Ladybird in the current copies of those
files, so we just need to ensure to keep Ladybird up to date for any
changes made upstream.