The setting for the search engine to use is currently ephemeral. Once we
have a settings dialog, we can implement this setting there, and persist
that setting.
This lets the user zoom in and out on a web page using the View menu or
keyboard shortcuts. This does not implement zooming with ctrl+scroll.
In the future, it'd be nice to embed the zoom level display inside the
location toolbar. But to do that, we will need to invent our own custom
search field and all of the UI classes (controller, cell, etc.) to draw
the field. So for now, this places the zoom level display to the right
of the location toolbar.
This is in the spirit of commit a4692a6c978a6e66d171e003063449790a6c5879
(and the history behind that commit).
We will need to perform lookups from an integral node ID to the JSON for
that node frequently in the Inspector. We will also need to traverse the
DOM tree from a node, through its ancestors, to the root node. These are
essentially the same maps stored by the Qt Inspector widget.
This commit includes only fetching the DOM tree from the WebContent
process and displaying it in an NSOutlineView. The displayed tree
includes some basic styling (e.g. colors).
After moving to navigables, we started reusing the code that populates
session history entries with the srcdoc attribute value from iframes
in `Page::load_html()` for loading HTML.
This change addresses a crash in `determine_the_origin` which occurred
because this method expected the URL to be `about:srcdoc` if we also
provided HTML content (previously, it was the URL passed along with the
HTML content into `load_html()`).
These classes are used as-is in all chromes. Move them to LibWebView so
that non-Serenity chromes don't have to awkwardly reach into its headers
and sources.
This adds menu items to open an interactive JavaScript console for a web
page. This more or less mimics the Qt implementation of the console.
Hooks are included to tie the lifetime of the console window with the
tab it belongs to; if the tab is closed, the console window is closed.
The LadybirdWebView currently assumed it is viewed with a Tab instance.
This will not be true with the JavaScript console. This patch removes
this assumption by plumbing WebContent callbacks through a new protocol.
The Tab interface then implements this protocol.
For example, the JavaScript console will invoke window.scrollTo(0, INF)
to scroll to the bottom of the console after updating its contents. The
NSScrollView being scrolled here seems to behave oddly if we scroll
beyond its limit (e.g. mouse events stop working). Prevent this by
limiting scrolling to the NSScrollView's document rect.
We were relying on TabController setting the web view's initial viewport
in [TabController windowDidResize], which has been triggered when the
Tab is first created. However, it turns out that only happens due to the
toolbar being added to the Tab window, causing a resize event. When the
web view is embedded in a window without a toolbar, this resize event is
not triggered. Therefore, we must set the viewport ourselves when the
web view is added to a window.
Currently, the only NSWindow type in the AppKit chrome is the Tab. Once
we have other window types (e.g. Inspector), commands which assume they
are used on a Tab will either crash or behave weirdly.
This changes the createNewTab: command to accept the tab from which the
new tab is created, rather than assuming that tab is the key window. So
if some JS on a page calls window.open() while a non-Tab window is key,
the new tab will be opened within the same tab group.
This also changes closeCurrentTab: to work on any key window. Regardless
of whether the key window is a Tab or some other window, pressing cmd+W
should just close that window.
This lets the user choose a color scheme which differs from the active
system theme. Upon changing the color scheme, the scheme is broadcast to
all active tabs, and will be used in new tabs.
We can easily add hooks to notify the browsers of these events if any
implementation-specific handling is needed in the future, but for now,
these only repaint the client, which we can do in ViewImplementation.
Storing the backup bitmap is the same across Browser and Ladybird. Just
peform that work in LibWebView, and handle only the implementation-
specific nuances within the browsers.
This also sets the default callback to do what every non-Serenity
browser is doing, rather than copy-pasting this callback into every
implementation. The callback is still available for any platform which
might want to override the default behavior. For example, OOPWV now
overrides this callback to use FileSystemAccessClient.
