This adds a motion preference to the browser UI similar to the existing
ones for color scheme and contrast.
Both AppKit UI and Qt UI has this new preference.
The auto value is currently the same as NoPreference, follow-ups can
address wiring that up to the actual preference for the OS.
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.
If we get a suggestion from fontconfig, we try those fonts first, before
falling back on the hard coded list of known suitable fonts for each
generic family.
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.
For some reason, moving the UI-specific CMake to its own files prevents
resource files from being copied to the Resource directory in the macOS
application. I'm not sure what the difference here is, but doing this
step during create_ladybird_bundle() works.
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 closes the window at WebContent process startup where we were
relying on Gfx::FontDatabase having some resolvable value in its default
font query.
