Comment by The-Compiler | Hacker News Reader

Comment by The-Compiler | Hacker News Reader

Parent Full thread

I agree, all approaches to this have some kind of major drawback. The main pain point with the approach chosen by qutebrowser is probably missing support for WebExtensions (i.e. Chrome/Firefox extensions), though I still hope that'll change with QtWebEngine some day: https://bugreports.qt.io/browse/QTBUG-61676

Other similar projects are using WebKitGTK, or indeed Electron: https://vieb.dev/ - again, probably not better/worse than QtWebEngine, just a different set of problems.

qutebrowser actually has an abstraction layer over the backend (which is why it can support QtWebEngine and the older/outdated QtWebKit, with little effort needed to keep support for the latter). If there is some new kind of library appearing some day which can draw to a Qt window and used from Python, it'd totally be possible to add support for it to qutebrowser without too much effort.

I had hoped for Servo to fill that gap at some point, but so far that hasn't happened yet: https://github.com/servo/servo/issues/27579

Another possibility is for Geckoview to be ported to Desktop platforms some day: https://mozilla.github.io/geckoview/ - something the people behind Tridactyl would like to happen: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64

As for extensions - other replies to your comment already mention this, but the main problem is that the WebExtension API is very constrained. On top of that, there's no API for handling keyboard input, so those extensions work by injecting JavaScript code handling keyboard inputs into every page you visit. That works, but only barely - lots of hacks are required for those kind of WebExtension limitations, and they won't work on pages where Mozilla decides extensions can't inject JS (such as internal pages or the Mozilla addons page). Again the folks behind Tridactyl have some ideas on how to improve the situation, but so far this hasn't happened yet: https://tridactyl.xyz/ideas/#write-a-keyboard-api-for-firefo...

Thanks for the detailed answer.

Many years ago, I considered adding an embedded browser (or just HTML renderer) into a game, as a simple way to build the game menu. The requirements mostly were:

- We needed the raw pixels as output. This was SDL, and the game was purely pixel based. Should also support alpha channel / transparency if possible. Also we would need to be in full control of all input events (keyboard inputs, mouse clicks), and have some easy way to handle some events like button clicks etc.

- Cross-platform (at least Windows, Linux, Mac, iOS, Android, and potentially more). Should also be easy to build, and not have much dependencies.

- It should be a small dependency (WebKit was way overkill; or maybe you can build a stripped down version?).

We gave up. Although we didn't really needed all the modern HTML features, and also no JS. I guess for a projects like yours, you have somewhat different requirements.

I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream.

I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now.

https://github.com/albertz/Pyjector https://github.com/albertz/chromehacking/blob/master/chromeh... https://src.chromium.org/viewvc/chrome/branches/874/src/chro...

I've recently learned about litehtml, which seems pretty much what you are describing: http://www.litehtml.com/

Looks like it started in 2012, but I've never heard about it until a recent plan from Qt to write a wrapper around it:

https://lists.qt-project.org/pipermail/development/2021-Janu...

(Probably so that simple things like their help viewer don't need a rather heavy QtWebEngine)

Whoops, I forgot about the other things I wanted to reply to :)

> I wonder if it is worth it to fork an existing browser (Chromium, Firefox) for your purpose. But this is probably impossible to maintain and keep in sync with upstream.

Yeah. People have suggested that in the past, but keeping up with e.g. Chromium is insane. When QtWebEngine updates their Chromium snapshot (a subset of the entire source) all couple of months, we're talking about millions of changed lines, and I've heard they need around a person-month every time to adjust their stable API to that.

Also see:

- https://chromium.googlesource.com/chromium/src.git/+log - https://twitter.com/the_compiler/status/1330896103911264257

It's pretty much a commit all couple of minutes, almost around the clock.

> I wonder whether there are other simple ways to hook into the browser. After all, you are in control of the OS, and you can inject some code. On MacOSX, there was actually some nice way to script things like this. But I think they restricted that very much now.

I was actually wondering what someone could do via ChromeDriver: https://chromedriver.chromium.org/

But I suppose the kind of UI/UX you could build with that would still be quite limited, perhaps even more so than what WebExtensions like Vimium or Tridactyl can do.

Reply on news.ycombinator.com