By Setting setBordered propperty on header buttons to `Yes` this
path makes the whole button clickable. Previously the only the
icon was clickable, now it's easy to click.
This large commit also refactors LibWebView's process handling to use
a top-level Application class that uses a new WebView::Process class to
encapsulate the IPC-centric nature of each helper process.
In the upcoming changes, Skia painter will be switched to Metal backend,
so we can no longer assume `pitch = width * 4` while reading Gfx::Bitmap
that wraps IOSurface populated by writing into MTLTexture that has
padded scanlines.
Previously, autocomplete was cleared before the results for the current
query were retrieved. The new results would then be added when the
network request completed. This resulted in a noticable flicker. The
results are now updated when the request for the current query is
completed.
There is a small behavior change in that the query itself is no longer
included in the autocomplete dropdown unless the list would otherwise
be empty.
This was only put in place because on SerenityOS, we wanted to use the
pid of the WebContent process, rather than the peer pid for the socket.
When launching with SystemServer, this got annoying. However, now that
we only have the case that the UI process spawns processes, we can
get rid of this hack. This restores the ability to see WebContent
processes' statistics in the task manager widget.
This is the same behavior as RequestServer, with the added benefit that
we know how to gracefully reconnect ImageDecoder to all WebContent
processes on restart.
The placeholder text shows "Search or enter web address" which doesn't
tell the user about *how* the search will be performed. Other popular
open source browsers show the search engine that will be used. For
example:
Chromium: "Search **engine** or type a URL"
Firefox: "Search with **engine** or enter address"
This change changes the placeholder text of the location bar to show
"Search with **engine** or enter web address".
Using mmap-allocated memory for backing stores does not allow us to
benefit from using GPU-accelerated painting, because all the performance
increase we get is mostly negated by reading the GPU-allocated texture
back into RAM, so it can be shared with the browser process.
With IOSurface, we get a framebuffer that is both shareable between
processes and can be used as underlying memory for an OpenGL/Metal
texture.
This change does not yet benefit from using IOSurface and merely wraps
them into Gfx::Bitmap to be used by the CPU painter.
Allows WebContentClient to get pid of WebContent process right after
creation, so there is no window between forking and
notify_process_information() IPC response, when client doesn't know the
pid.
In the upcoming changes, we are going to switch macOS to using an
IOSurface for the backing store. This change will simplify the process
of sharing an IOSurface between processes because we already have the
MachPortServer running in the browser, and WebContent knows how to
locate the corresponding server.
LibLocale was split off from LibUnicode a couple years ago to reduce the
number of applications on SerenityOS that depend on CLDR data. Now that
we use ICU, both LibUnicode and LibLocale are actually linking in this
data. And since vcpkg gives us static libraries, both libraries are over
30MB in size.
This patch reverts the separation and merges LibLocale into LibUnicode
again. We now have just one library that includes the ICU data.
Further, this will let LibUnicode share the locale cache that previously
would only exist in LibLocale.
This patch adds a simple in-memory HTTP cache to each WebContent
process.
It's currently off by default (turn it on with --enable-http-cache)
since the validation logic is lacking and incomplete.
The location bar URL is no longer hidden when creating a new tab or
opening a new window that has an associated URL. Conversely, the
location bar is now always focused and the URL hidden when creating a
window or tab without an associated URL.
The location bar is focused when:
* Opening the browser from the command line with no URL arguments
* Opening a new tab (Ctrl+T)
* Opening a new window (Ctrl+N)
The location bar is not focused when:
* Opening the browser from the command line with one or more URLs
* Opening hyperlinks in a new tab
* Clicking a hyperlink with `target="_blank"`
This matches the behavior of other major browsers.
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.
