The hackish initial loading of about:blank was previously added to the
history, so you could go back to it (which wasn't very ergonomic). Now
we set the m_is_history_navigation flag before loading it so it doesn't
get added to the history.
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.
Previously we were always pushing to history on the on_load_start
callback. Now we only do that if we are NOT navigating through the
history navigation (loading pages by going back/forward). This is what
the SerenityOS browser does:^)
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's no point in busy-waiting for the condition to come true.
By passing the `WaitForMoreEvents` flag to `processEvents()`, we allow
Qt to block until it has something for us to react to.
This was extremely noticeable when waiting for large resources to
finish loading.
The slowdown is sometimes 5x, possibly more.
This is trivially confirmed by adding a large JS file to a page and
comparing the load time with a simple wget.
- Add Qt::Core, Qt::Gui, LibGfx, LibIPC, and LibJS to the ladybird
target, remove LibGL, LibSoftGPU, and LibWebSocket
- Add LibJS to the WebContent target, remove LibWebView
- Order them properly :^)
Regressed in https://github.com/SerenityOS/serenity/pull/15746.
Fixes#108.
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.
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.
Qt can wrap any number of cookies into a single Set-Cookie header in the
network responses it gives us. We now use the QNetworkReply::header()
API to get a "cooked" list of the cookies, and then rewrap them in a
format suitable for LibWeb.
Sites that send multiple Set-Cookie headers in one response now work
a lot better. :^)
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.
This causes CMake to output a WebContent build, without this it would
not build WebContent and Ladybird would be unusable since it couldn't
find the WebContent executable.
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. :^)
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>
For the first cut, the file path is not configurable and the content
filter cannot be toggled on or off. If we fail to apply the content
filters for any reason (e.g. the filter file doesn't exist), we simply
just stop loading the content filters to allow using Ladybird without
content filters.
