The URL is now not shown when a new tab is initially activated until
the location bar loses focus. This allows the user to see the location
bar placeholder text when opening a new tab. It also makes it easier to
paste URLs into the location bar after opening a new tab.
This commit adds the standard shortcuts for the Find Next and Find
Previous buttons on the find in page panel. These shortcuts are usually
F3 and Shift+F3 respectively, although Qt standard shortcuts may vary
across platforms.
On my system `QKeySequence::StandardKey::ZoomIn` includes both `Ctrl++`
and `Ctrl+=`, so explicitly adding the secondary `Ctrl+=` shortcut
ourselves results in an ambiguous shortcut error message being shown.
According to the Qt documentation the key bindings returned by
`QKeySequence::StandardKey::*` are platform specific, so we may still
need to add the secondary shortcut on some systems. Therefore, we now
check whether our secondary shortcut is already in the shortcut list
before adding it.
The placeholder text is there to prompt the user as to what could be
added in the address bar. The current text tells the user that they can
"Search or enter web address" even when the search setting is disabled.
When attempting to "Search" the user is instead sent to page ":", with
an error in the console:
WebContent(575249): (FIXME) Don't know how to navigate to :
This patch fixes this by checking whether the search feature is enabled
and setting the placeholder appropriately. This provides a slightly
better user experience.
Closes#132
Before we had HTTP::HeaderMap (which preserves multiple headers with the
same name), we collected multiple "Set-Cookie" headers and bundled them
together as a JSON array.
This was a huge hack, and now we can stop doing that, since LibWeb gets
access to the full set of headers now.
Instead of using a HashMap<ByteString, ByteString, CaseInsensitive...>
everywhere, we now encapsulate this in a class.
Even better, the new class also allows keeping track of multiple headers
with the same name! This will make it possible for HTTP responses to
actually retain all their headers on the perilous journey from
RequestServer to LibWeb.
This makes WebView::Database wrap around sqlite3 instead of LibSQL. The
effect on outside callers is pretty minimal. The main consequences are:
1. We must ensure the Cookie table exists before preparing any SQL
statements involving that table.
2. We can use an INSERT OR REPLACE statement instead of separate INSERT
and UPDATE statements.
The "Enable Scripting", "Block Pop-ups" and "Enable Same-Origin Policy"
options are now set for every tab when toggled. They are also applied
to new tabs when they are created.
The main intention of this change is to have a consistent look and
behavior across all scrollbars, including elements with
`overflow: scroll` and `overflow: auto`, iframes, and a page.
Before:
- Page's scrollbar is painted by Browser (Qt/AppKit) using the
corresponding UI framework style,
- Both WebContent and Browser know the scroll position offset.
- WebContent uses did_request_scroll_to() IPC call to send updates.
- Browser uses set_viewport_rect() to send updates.
After:
- Page's scrollbar is painted on WebContent side using the same style as
currently used for elements with `overflow: scroll` and
`overflow: auto`. A nice side effects: scrollbars are now painted for
iframes, and page's scrollbar respects scrollbar-width CSS property.
- Only WebContent knows scroll position offset.
- did_request_scroll_to() is no longer used.
- set_viewport_rect() is changed to set_viewport_size().
This was no longer doing anything. We'll eventually want a way to pass
system default fonts to each WebContent process, but we don't need to
squeeze everything through this API that was really meant for Serenity's
very idiosyncratic font system.
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.
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
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.
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.
