qbrt's memory usage is high (or at least higher than Electron's)

[mykmelez]

This tweet notes high memory usage for qbrt with a "hello world" app, especially relative to Electron. We've done no optimization for memory footprint, so this isn't necessarily unexpected, but it's worth investigating.

[fasterthanlime]

Hi!

I haven't opened an issue about this because I figured it was already on your radar, or you just had many other things on your plate before worrying about this.

Also - perhaps that's one thing servo will help with eventually? And finally, it didn't feel right to open an issue I know I won't have time to follow up on.

That said, props for relaying it here, I'm keeping a distant but watchful eye on qbrt 🌟

[mykmelez]

I haven't opened an issue about this because I figured it was already on your radar, or you just had many other things on your plate before worrying about this.

Right, it's still early days for this project, so we aren't necessarily worrying about this yet, although it's still on my mind.

Also - perhaps that's one thing servo will help with eventually?

That's possible, although I expect to be able to achieve decent memory footprint with Gecko as well.

And finally, it didn't feel right to open an issue I know I won't have time to follow up on.

No worries, tweeting is fine! I only opened the issue to make sure I don't forget about it. 😄

That said, props for relaying it here, I'm keeping a distant but watchful eye on qbrt 🌟

Sounds good! Let me know if I can answer any questions or provide more detail about anything.

[fritzy]

Someday, it'd be awesome to ship a slimmed down executable that was purpose built for qbrt. I'd do that when your project shows signs of success. I am enamored with it.

[mykmelez]

Indeed, my intention with qbrt isn't necessarily to use Firefox as the runtime in perpetuity. Firefox is a great way to bootstrap the project, and it's possible to strip the Firefox distribution of much of the Firefox code (especially the front-end code). But in the long run it probably makes sense to build a custom runtime for qbrt.

Doing so is complicated by the time it takes to build Gecko. None of the commercial CI services—Travis CI, CircleCI, etc.—allow jobs to run long enough to build Gecko. I hoped to be able to use Travis's new support for "build stages" to build Gecko across several jobs, but Gecko's build process is hard to split into small enough parts. It's possible to build each "tier" separately, but the "compile" tier still takes too long.

It might be possible to use Mozilla's TaskCluster service to build Gecko, but that service is not yet generally available to Mozilla-related projects, and it isn't clear if/when that'll change. In the meantime, Firefox is the best available runtime and has the advantage of significant and ongoing investment in build/release infrastructure.

[fritzy]

I wonder if Firefox Focus would provide a more slimmed down base, or at least an example of one.

[mykmelez]

Firefox Focus uses the Android System WebView, and its separation of concerns (between rendering engine, application, and possibly application framework) may be somewhat Android-specific, so I'm not sure how much of the actual code could be reused.

However, it may be a good example of a general approach to building applications on a runtime. And there's been work to use Gecko in Focus, so it might indeed prove useful for qbrt. At the very least, you've reminded me that I should learn more about its architecture!

[benfrancis]

The work to use Gecko in Focus is with GeckoView and from my experimentation there's currently no way to package or run HTML chrome, you have to write the browser chrome as native Android UI (Java). That's what I'm currently doing for my mobile prototyping.

With a custom stripped down Gecko (Quantum) runtime, qbrt could be a viable alternative to Electron on the desktop, and a successor to XULRunner.

I'm currently using Electron for prototyping but it's really not designed for building browsers (they removed the Chromium sandbox). I'd like to switch back to qbrt, if the developer tools start working again and I can debug the other regressions I've experienced, but it's currently more likely I'll eventually have to switch to Muon, Brave's fork of Electron which is better suited to developing browser-like applications.

Another thing which could help make qbrt more attractive as an alternative to Electron would be to clean up the mozbrowser API under a new chrome-only <webview> tag, as planned in this six year old bug. Unfortunately the bug reporter and the owner and one of the peers of that Gecko module have all since left Mozilla.

[mykmelez]

I'm currently using Electron for prototyping but it's really not designed for building browsers (they removed the Chromium sandbox). I'd like to switch back to qbrt, if the developer tools start working again and I can debug the other regressions I've experienced, but it's currently more likely I'll eventually have to switch to Muon, Brave's fork of Electron which is better suited to developing browser-like applications.

DevTools are working again, but the DevTools team doesn't support them, so they could break at any time, which makes it hard to recommend qbrt as an alternative to Electron or Muon. cc: @jasonLaster for his thoughts on the feasibility of DevTools supporting multiple targets.

Another thing which could help make qbrt more attractive as an alternative to Electron would be to clean up the mozbrowser API under a new chrome-only tag, as planned in this six year old bug. Unfortunately the bug reporter and the owner and one of the peers of that Gecko module have all since left Mozilla.

Is it possible to do this on a branch of Gecko that doesn't break too frequently? I'm unfamiliar with the details of <iframe mozbrowser>, and I could imagine it needing to be tightly coupled to Gecko internals, such that maintaining a branch is unfeasible.

Neveretheless, if it is feasible, then it's a more probable path than awaiting support for embedding Gecko from Mozilla.

[benfrancis]

@mykmelez wrote:

DevTools are working again, but the DevTools team doesn't support them, so they could break at any time, which makes it hard to recommend qbrt as an alternative to Electron or Muon. cc: @jasonLaster for his thoughts on the feasibility of DevTools supporting multiple targets.

Since I wrote that last comment I came across an announcement from Brave that they're moving away from Muon to a Chromium front end. This makes it unlikely that Muon will be maintained going forward, which makes qbrt a more compelling option for browser-like applications again.

The DevTools instability is a bit of a problem, and some recent changes to Gecko mean I'd need to re-write a lot of front end code since insertAdjacentHTML is no longer allowed in chrome privileged JavaScript. The fact that qbrt still bundles the whole of Firefox is obviously also not ideal, but currently it is the best (only) option for embedding Gecko on desktop.

Is it possible to do this on a branch of Gecko that doesn't break too frequently? I'm unfamiliar with the details of <iframe mozbrowser>, and I could imagine it needing to be tightly coupled to Gecko internals, such that maintaining a branch is unfeasible.
Neveretheless, if it is feasible, then it's a more probable path than awaiting support for embedding Gecko from Mozilla.

I don't fancy maintaining a branch of Gecko, it kind of defeats the object of having a Gecko runtime if you have to build a custom Gecko binary anyway. The Browser API is indeed tightly coupled with Gecko internals like the docshell and process management. What I've done successfully before is to wrap <iframe mozbrowser> in a <web-view> web component to create a common abstraction on top of both <iframe mozbrowser> and Electron's <webview>, but in the end I decided that added too much overhead, especially given I had to use a polyfill for web components support in Gecko. Now that Gecko's web components implementation is getting closer to release that might be a more viable option. It doesn't help much with making Gecko embedding more attractive to others though.

Now that GeckoView is getting better support with production use, I'd really like to move back from Electron and Android WebView to qbrt and GeckoView. I realise my little project doesn't provide much of an incentive, but I hope that maybe some of the renewed enthusiasm for Gecko embedding might spill over from mobile back to desktop so that others can use Gecko in their projects too.