Restore the active tab's remembered focus widget when switching tabs.
If the tab has no remembered focused child, fall back to the web
view so keyboard scrolling works immediately in tabs opened from
links.
This keeps the existing new-tab location bar behavior while making
background-opened pages respond to keyboard inputs as soon as they
are activated.
In addition to Ctrl+PageDown and Ctrl+PageUp, also support Ctrl+Tab and
Ctrl+Shift+Tab to switch between browser tabs. This is the common
behavior in other browsers.
QTabWidget's built-in tab bar management made it difficult to properly
position the new tab button, and caused visual artifacts with the
separator line across themes.
Replace QTabWidget with a custom TabWidget that places a QTabBar
alongside an explicit new tab button. This us gives full control over
the tab bar row layout.
The HamburgerMenu subclass overrode showEvent() to reposition the menu
using move() after QMenu::popup() had already shown it. On the first
open, rect().width() could return a stale value, causing the menu to
appear detached from the button and truncated to a single item. The
move() call also bypassed Qt's screen boundary adjustments.
Instead, we can replace the HamburgerMenu with a normal QMenu, and use a
custom HamburgerButton class for the menu's tool button. In this class,
we override mousePressEvent() to call popup() with the correct right-
aligned position before the menu is shown. This lets Qt manage sizing
and screen boundaries correctly.
This adds the following features to the Qt UI:
- An "exit fullscreen" button that displays when entering fullscreen
This will disappear after a certain amount of time. Moving the
cursor to the top of the screen will make it reappear.
- Switching tabs exits fullscreen
The look and feel of this is preliminary and should be expanded upon
in the future.
These IPC methods should be expanded in the future to allow WebContent
to specify what UI elements should be kept/removed, for example, the
navigation UI.
This lets us avoid each UI needing to handle link clicks directly, and
lets actions stored in LibWebView avoid awkwardly going through the link
click callbacks to open URLs.
By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now
in sync - the AppKit UI was previously missing some actions.
Further, this inadvertently fixes bugs around applying debug settings to
new web views, especially across site-isolated processes. We were
previously not applying settings appropriately; this now "just works" in
the LibWebView infra.
This migrates all duplicated context menus from the UIs to LibWebView.
The context menu actions are now largely handled directly in LibWebView,
with some UI-specific callbacks added to display e.g. confirmation
dialogs.
Actions that only ever apply to a specific web view are stored on the
ViewImplementation itself. Actions that need to be dynamically applied
to the active web view are stored on the Application.
This replaces the --devtools-port flag with a --devtools flag, which
optionally accepts a port. If the --devtools flag is set, we will now
automatically launch the DevTools server.
This removes the old autoplay allowlist file in favor of the new site
setting. We still support the command-line flag to enable autoplay
globally, as this is needed for WPT.
This replaces the existing menu item that would open the Qt settings
dialog. That menu item still exists, but is no longer the default
settings action.
This adds a WebView::Settings class to own persistent browser settings.
In this first pass, it now owns the new tab page URL and search engine
settings.
For simplicitly, we currently use a JSON format for these settings. They
are stored alongside the cookie database. As of this commit, the saved
JSON will have the form:
{
"newTabPageURL": "about:blank",
"searchEngine": {
"name": "Google"
}
}
(The search engine is an object to allow room for a future patch to
implement custom search engine URLs.)
For Qt, this replaces the management of these particular settings in the
Qt settings UI. We will have an internal browser page to control these
settings instead. In the future, we will want to port all settings to
this new class. We will also want to allow UI-specific settings (such as
whether the hamburger menu is displayed in Qt).
The "disable DevTools" button looked like a "close this notification"
button to me, and although a tooltip was set, it only showed up
immediately on the AppKit UI and not the Qt version.
This makes the behavior of clicking the disable button a lot clearer by
showing a button with "Disable" as its title.
This brings keyboard shortcuts for the inspector up with common
convention in FF and Chrome: Ctrl+Shift+C now also opens the inspector,
and F12, Ctrl+W, and Ctrl+Shift+I now close the inspector when the
inspector window is focused.
Resolves#972
