Any bitmap load of the style load_from_file("/res/foo") has been
converted to the new pattern load_from_uri("resource://foo").
This will allow for porting more apps to non-serenity targets, as well
as add some flexibility if we want to experiment with other resource
storage formats in the future.
clang-format-20, as used in CI, doesn't catch these instances. On my
machine, I have clang-format-21, which does. Since we plan to move to
clang-format-22 at some point in the future, let's fix these up now.
These files will be touched soon, so let's fix up some feng shui before
the real changes to make the code formatter happy.
This adds a global search term stored in BrowserWindow that is shared
across all tabs. When opening Find in Page (Ctrl+F), the widget now
uses the following priority logic:
1. If there's text selected on the page, use that
2. If the search box is empty, use the global search term
3. Otherwise, keep the existing text
To imitatates Chromium's logic, the global search term is updated
whenever the user types, navigates matches, or when a selection
populates the search box.
This adds a FindInPageWidget to the Browser application, allowing users
to search for text within the current tab.
Features:
- Search textbox with real-time search as you type
- Previous/Next buttons with up/down arrow icons
- Match Case checkbox to toggle case sensitivity
- Result label showing "X of Y matches" or "Phrase not found"
- Close button to hide the widget
Keyboard shortcuts:
- Ctrl+F: Open find-in-page widget
- Enter: Jump to next match
- Shift+Enter: Jump to previous match
- Escape: Close the widget
The widget integrates with LibWebView's existing find_in_page,
find_in_page_next_match, and find_in_page_previous_match APIs.
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.
(cherry picked from commit 1aab7b51ea9c27a6ffff8df0c8bcbec87680865c;
amended to update `on_received_source` signature in Browser too)
In all instances, it should be clear that the jailing of a process is
ending when the process exits.
This is a preparation before introducing another option to set a process
as jailed until it calls the execve syscall.
The default limit (at least on Linux) causes us to run out of file
descriptors at around 15 tabs. Increase this limit to 8k. This is a
rather arbitrary number, but matches the limit set by Chrome.
(cherry picked from commit d58a8b514647a1137d76a1d601f0c325a51f29b3;
amended to also update Userland/Applications/Browser/main.cpp)
These programs are capable of running other programs, so we should
restrict them from potentially running SUID programs, which was never a
functionality we supported for those programs anyway.
This patch adds the common Ctrl-W shortcut to make_quit_action as an
alternate shortcut by default.
The shortcut can be disabled in programs using this key binding for a
different purpose, e.g. closing tabs, or instances where the "close
window" concept would not be applicable, such as CatDog.
To the best of my knowledge, I have disabled the shortcut for any
existing programs in the system where the aforementioned examples or any
additional conflicts would apply.
Ran into a crash here while testing LibProtocol changes. The method we
invoke here (did_progress) already accepts an Optional, and handles when
that Optional is empty. So there's no need to assume `total_size` is
non-empty.
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.
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
'set_frame_style' is what Frame itself uses to set the value, and a
significant number of GML files use 'frame_style' instead of just
'style', so let's switch to it and use it everywhere consistently.
This partially supports the WebView::ChromeProcess mechanics. New
windows aren't totally supported and will just open a new tab for now.
When launched via the Browser's AppFile (either through quick launch or
the desktop shortcut), a new window will be requested.
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.
When audio begins playing, add a button to the left of the favicon 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 ensures we consistently show a favicon and that we update the title
to at least display the page URL when there isn't a <title> tag. We
would otherwise continue displaying the previous page's title.
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.
This reverts commit 2e8ff1855c.
We had some awkward timing around the merging of this commit and commit
b073fdd570. With both commits in tree, we
are now processing hotkey activations twice. For example, ctrl+t will
open 2 tabs.
Before shortcuts like ALT-F4, etc did not work. This makes the window
ignore keydown events. In the future this may be altered to allow for
custom shortcuts from within ladybird?
We don't need to forward Cookie-related IPCs from the WebView through
the Tab to the BrowserWindow. We can skip the Tab like we do in other
chromes.
This is primarily to reduce overhead when changing Cookie IPCs in future
patches.
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).
Andrew Kaster