I installed qutebrowser from haiku depot x86 and I got this error message on startup. Anybody familiar with this? And what the cure might be?
You’re using obsolete code. QtWebKit is the replacement for QtWebEngine. It isn’t fully backwards compatible. (Or maybe the other way around? I don’t remember.)
OK, so I forced the QtWebKit backend choice in the dialog. The browser opened and crashed but ran enough to see several error messages, one being: QtWebKit release notes > WARNING: This release [of QtWebKit] is based on [an] old WebKit revision with known unpatched vulnerabilities. Please use it carefully and avoid visiting untrusted websites and using it for transmission of sensitive data.
It’s recommended that you use QtWebEngine instead.
So which is current / correct?
A quick Google search revealed https://github.com/qutebrowser/qutebrowser/issues/4039
Thanks. It seems the maintaner of qutebrowser cannot decide so it seems this browser is a no go at the moment.
We don’t have the new qwebengine for haiku (because it’s based on blink and google isn’t really supportive of porting blink to other platforms than linux and windows). So all our qt browsers are stuck with qtwebkit, which qt is not maintaining anymore. They will all become more and more unusable as the web moves on.
Thank you for the explanation! Hoping the vacation is great!
Forgive the dumb question, does this affect WebPositive or does it use a web engine that is being updated?
No, WebPositive uses another engine: Webkit.
To be more precise, qtwebkit and webkit are the same engine at the core. qtwebkit is a version of webkit with an API allowing to use it in Qt applications. WebPositive is not a Qt application, so it uses a webkit with a different API, allowing to use it in native Haiku applications. This one is still being updated and regularly integrates the changes from webkit (work done there by Apple (they use it for Safari), Sony (for the Playstation browser), and Igalia (who maintains the GTK version as well as a version called WPE which is for embedded platforms). All of these are synchronized regularly so we benefit from each other’s work (well, with not much work done by Haiku developers at the moment, we probably benefit more than we give to the others).
Ah thank you! Precision matters. All of haiku (users and developers) should rally around WebPositive then. What are the biggest hurdles in your estimation to WebPositive being robust for use (video, web apps, standards compliance, stability)?
We need more people to look into the code and fix the bugs.
In terms of standards compliance, we are missing some things but I don’t feel they are really important (gamepad support, geolocation, …).
The video code has to be rewritten by someone who actually knows something about media kit, the current code is a hack using the game kit I wrote in half a day to see what needed to be done. This part of the code is also responsible for most freezes of the app (because of threading issues, the whole browser is blocked while downloading a video or audio file).
“web apps” does not mean anything in particular, each of them needs to be reviewed and the problems fixed one at a time. Most of the issues will be either in drawing operations (we implement them using BView/app_server, and we can either use the API incorrectly, or hit bugs in it), or in the network code (we have our own implementation of an HTTP client and it needs improvements and bugfixes).
So, it’s just a matter of people looking into it and taking time to investigate and fix the problems, one at a time. Some bugs will also be on WebKit side and go away “on their own” as we integrate new versions of WebKit in our code (I usually take care of this part).