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
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.
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.)
This handles most (?) of keyboard input. For some reason, "Ctrl+A"
and Enter are not working on google.com.
It can handle plain ASCII, I tested also Hebrew input,
and https://playbiolab.com/ (which is playable now!)
Build an Android APK file that, when configured properly in Qt Creator,
can be used to deploy the browser to an Android device.
The current build requires NDK 24, targets no less than Android API 30,
and Qt Creator 6.4.0.
This patch takes the browser history code from the Serenity browser and
wires it up to the QT interface. This is tied in with a few extra
toolbar buttons associated with each tab.
Until we can get our own RequestServer infrastructure up and running,
running the TLS and HTTP code in-process was causing lots of crashes
due to unexpected reentrancy via nested event loops.
This patch adds a simple backend for HTTP and HTTPS requests that simply
funnels them through QNetworkAccessManager.
On high-dpi systems QT will automatically scale up painting operations.
This results in an ugly blurry browser window surrounded by a nicely
scaled window frame. This patch applies an inverse scale to the WebView
widget, ensuring the painting and mouse events are lined up and draw
with a 1:1 pixel ratio with respect to the display's device pixels.
