Open mykmelez opened 7 years ago
fasterthanlime
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago 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
commented
7 years ago I wonder if Firefox Focus would provide a more slimmed down base, or at least an example of one.
mykmelez
commented
7 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago @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
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.