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.
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.
There are a lot of unsupported mouse click events that the engine
cannot handle. It such event (0) reaches the web engine - it will
assert.
Don't even propagate them - this is the safe way. As of today!
I also added back/forward buttons to the translation.
Should fix#27
This commit changes how we set the back and forward button key bindings
to use platform-specific standard key sequences.
For example, in Mac OS X, the back action will be now triggered via
Cmd+← and Cmd+[, whereas previously the action was mapped to Alt+←,
which is not standard in Mac OS X.
This setup should allow the package maintainers who are looking to
distribute ladybird on their distributions to use CMake to install
ladybird using cmake install rules rather than having to write their own
Reorganize the logic for initializing s_serenity_resource_root.
Now, we initialize it in platform_init(), and move platform_init to the
top of initialize_web_engine.
Add a branch at the end of the function to check
``QApplication::applicationDirPath()`` for the location of the
executable, and base the location of resources on that.
In an installed configuration, this will be /some/path/bin, with the
resource root set to /some/path/share/, looking for files in
/some/path/share/res/resource-type.
This matches up with some upcoming CMake changes to install resources in
CMAKE_INSTALL_DATADIR.
