This commit adds the common actions you'd expect to the Ladybird context
menu, arranged like so:
┌──────────────────────────────┐
│ Go Back Alt+Left │
│ Go Forward Alt+Right │
│ Reload Ctrl+R │
│ ──────────────────────────── │
│ Copy Ctrl+C │
│ Select All Ctrl+A │
│ ──────────────────────────── │
│ View Source Ctrl+U │
│ Inspect Element │
└──────────────────────────────┘
This adds "Inspect Element" (currently the only entry) to the context
menu for the page, which will do what you expect (most of the time),
and bring up the Inspector with hovered element selected.
This aligns the Ladybird console implementation with the Browser console
a bit more, which uses OutOfProcessWebView for rendering console output.
This allows us to style the console output to try and match the system
theme.
Using a WebContentView is simpler than trying to style the old QTextEdit
widget, as the console output is HTML with built-in "-libweb-palette-*"
colors. These will override any color we set on the QTextEdit widget.
This adds a -P option to run Ladybird under callgrind. It starts with
instrumentation disabled. To start capturing a profile (once Ladybird
has launched) run `callgrind_control -i on` and to stop it again run
`callgrind_control -i off`.
P.s. This is pretty much stolen from Andreas (and is based on the patch
everyone [that wants a profile] have been manually applying).
This will avoid loading starting about:blank page in places when we know
exactly what we want to load.
The opening in background part might be useful for future things like
file drops and right-click open in new tab.
On many keyboards, Ctrl++ is actually Ctrl+Shift+=, and Ctrl+= makes
more sense as it's symmetric with Ctrl+-.
Both Firefox and Chrome already support this alternate shortcut,
so let's be nice and support it in Ladybird as well. :^)
This allows us to use standard Serenity IPC infrastructure rather than
manually creating FD-passing sockets. This also lets us use Serenity's
WebDriver Session class, removing the copy previously used in Ladybird.
This ensures any changes to Session in the future will be picked up by
Ladybird for free.
This adds a SQLServer binary for Ladybird to make use of Serenity's SQL
implementation. This has to use the same IPC socket handling that was
used to make WebContent and WebDriver work out-of-process.
Unlike Serenity, Ladybird creates a new SQLServer instance for each
Ladybird instance. In the future, we should try to make sure there is
only one SQLServer instance at a time, and allow multiple Ladybird
instances to communicate with it.
The WebDriver will pass the --webdriver-fd-passing-socket command line
option when it launches Ladybird. Forward this flag onto the WebContent
process, where it will create the WebDriverConnection for IPC.
Steps to reproduce:
1. Open the Cookie Clicker game in a tab.
2. Open another website in another tab and make that the current tab.
3. Observe how the window's title mentions Cookie Clicker.
This patch brings over the WebContent process over from SerenityOS
to Ladybird, along with a new WebContentView widget that renders
web content in a separate process.
There's a lot of jank and FIXME material here, notably I had to re-add
manually pumped Core::EventLoop instances on both sides, in order to get
the IPC protocol running. This introduces a lot of latency and we should
work towards replacing those loops with improved abstractions.
The WebContent process is built separately here (not part of Lagom) and
we provide our own main.cpp for it. Like everything, this can be better
architected, it's just a starting point. :^)
This prevents memory leaks detected by both Valgrind and ASAN/LSAN.
Valgrind is still suspicious of the leaked JS::VM from
Web::Bindings::main_thread_vm() but there's other issues with leak
checking all the GC'd objects.
Co-Authored-By: Diego Iastrubni <diegoiast@gmail.com>
We use a ModelTranslator to expose a DOMTreeModel from LibWebView :^)
It allows you to select the currently inspected node, which causes
the engine to render a little box model overlay above the web content.
This will allow us to share code with LibWebView from SerenityOS.
(This would otherwise not work, since its "WebView" namespace collides
with our "WebView" class.)
Also, we should eventually move towards a more sophisticated
multi-process WebView like OOPWV.
This allows requests like dumping the DOM tree to be forwarded to the
correct tab. Otherwise, the event would be forwarded to the most
recently created tab.
This patch removes the dual-event-loop setup, leaving only the Qt event
loop. We teach LibWeb how to drive Qt by installing an EventLoopPlugin.
This removes the 50ms latency on all UI interactions (and network
requests, etc.)
