This has been broken since the switch to the multiprocess architecture
(and even before then was very limited).
This restores the previous functionally and also implements the ability
to inspect individual elements (by selecting them in the tree view).
The inspector also now correctly updates when navigating between pages.
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.
We now replace the current history entry if the page-load has been
caused because of a redirect. This makes it able to traverse the
history if one of the entries redirects you, which previously
caused an infinite history traversion loop.
Depends on https://github.com/SerenityOS/serenity/pull/16004
Similar to https://github.com/SerenityOS/serenity/commit/9782660. Unlike
Serenity's browser, this doesn't affect reloading the page, as Ladybird
refers to the History object for reloading (which is updated already on
page load). However, this URL is used for e.g. crash reporting, so let's
update it here as well.
WebContent now needs to interact with these dialogs asynchronously. This
updates WebContentView to hold a pointer to whatever dialog is open, and
implements the methods to interact with that dialog.
This adds a WebDriver binary for Ladybird to make use of Serenity's
WebDriver implementation. This has to use the same IPC socket handling
that was used to make WebContent work out-of-process. Besides that, we
are able to reuse almost everything from Serenity.
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.
Rather than needing to set another environment variable for WebDriver's
passing socket, let's forward these FDs by command line. This also moves
the creation of the WebContent connection to a helper function so that
the WebDriver connection can re-use it.
Previously, reloading went back to the first page loaded by
WebView::load() or WebView::load_html(), as they are the only methods
that modify m_url, which is what the reload loaded. Now we handle
reloads in Tab.cpp by simply loading the last entry in the m_history.
We now emit a new signal for backward mouse button's mouseup and forward
mouse button's mouseup which is handled by going back and forward in the
history respectively:))
There are no custom changes for Ladybird in the current copies of those
files, so we just need to ensure to keep Ladybird up to date for any
changes made upstream.
This fixes a build issue introduced by https://github.com/SerenityOS/serenity/pull/15736.
These didn't work, for two reasons:
1. Qt swallows all Tab key presses by default. We have to override
the event() function in order to receive them.
2. Qt transforms Shift+Tab into a fake "Backtab" key. We have to
undo this transformation and send Shift+Tab to WebContent.
When spawning a WebContent process, we have to close the file
descriptors belonging to the "other side" in both processes, or they
will not get naturally "cleaned up" when one of the processes exits.
Fixes#93
Always call platform_init after there's a QApplication, because in the
installed configuration that's how we find the resources.
Try QCoreApplication::applicationDirPath() after looking in ./WebContent
for the WebContent process. In an installed configuration, ladybird and
WebContent will both be in $PREFIX/bin.
Add install rules for WebContent and its linked libraries, for if they
ever differ from ladybird's.
While this adds a fair bit of widget code, we're also increasing code
sharing by using the same bits in WebContentClient for interacting with
the JS console.
That said, we should look for more ways to share code here.
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. :^)
