After some consideration, I’ve decided to discontinue development of Positron.
Positron was an experimental runtime for creating desktop apps using web technologies. It was based on Firefox, and its principal feature was that it was Electron-compatible. I started working on it—in conjunction with several colleagues—to enable Tofino to run on Gecko.
But Tofino is dead (long live the Browser Futures Group!), and Electron compatibility isn’t essential for a viable Gecko runtime. It’s also hard, since Electron has a large API surface area, is a moving target, requires Node.js integration (itself a moving target), and is designed for Chromium’s process architecture, which is substantially different from Firefox’s.
I’ve previously written about the utility of desktop runtimes (among other embedding projects). I still think they’re valuable for a variety of use cases, and Gecko can provide unique value to desktop application development. I’ll continue to pursue the realization of that value. I just won’t do it through Positron.
This is very bad news.
What will replace Positron? With Mozilla Chromeless, XULRunner, mozApps and B2G now stopped it’s almost impossible to use Gecko for anything other than building Firefox.
Is GeckoView still active on mobile?
Ben
Ben, my current thinking about a replacement for Positron is to develop an experimental command-line tool that reuses a Firefox distribution as a runtime, provides Gecko’s existing system-integration APIs (XPCOM/JSM), and focuses on improving the experience of developing and packaging desktop apps using web technologies (HTML, JS, CSS).
From an experience perspective, installation should be as simple as:
npm install -g name-of-toolAnd running an app should require merely pointing the tool at its script entry point:
name-of-tool run path/to/app/main.jsWhile packaging an app into a redistributable package should be similarly a single command:
name-of-tool package path/to/app/(With a manifest for more significant configuration.)
My goal with that experiment would be to get to a minimum viable Gecko runtime that is immediately useful for a subset of cases and can be incrementally improved to support others.
It might also include support for Node via SpiderNode in the future. I’m not foreclosing that possibility. I’m only looking for a shorter path to minimum viability.
As for GeckoView, it remains active, and I’ll blog about it once I have something to say! In the meantime, follow the GeckoView MVP bug, the Core :: Embedding: APIs component, and the Firefox for Android :: GeckoView component for details.
Sounds interesting. Has any of this materialized? I am currently evaluating Electron to embed JVM into it, and stumbled on this. I would like a lighter alternative, without full libchromiumcontent!
I use the -app application.ini feature of Firefox to build XUL applications and single site browsers.
I’ve also found that it works as a pretty good replacement for XULrunner (at least for now).
Michael wrote:
Building something on Firefox is very different to building something on Gecko. I’d be surprised if anyone built any serious applications using that approach.
Myk wrote:
Does that mean that an application would have to include the whole of Firefox (including the browser UI) in its application package?
I’m pleased GeckoView is continuing 🙂 I assume the default way to use that will be to create a UI using Java rather than HTML, CSS & JavaScript though?
I’m not sure what you mean by “building something on Gecko,” but since there isn’t an extant Gecko desktop embedding API, currently the only way to build something on Gecko is to build a XUL application.
You can do that in-tree by adding a XUL app to a fork of mozilla-central, like Positron does; you can do it out-of-tree in a distinct repo that uses a copy of Firefox and its –app flag to run the app, which I suspect is what mkaply is doing; or you can take a hybrid approach like Thunderbird (although this is deprecated and only supported for that app).
In all cases, however, you’re building a XUL app, and a XUL app running on Firefox via –app is almost as capable and flexible as one built in-tree (except that you can’t make changes to Gecko itself).
So it isn’t clear to me why developers wouldn’t build serious applications with that approach. Firefox itself is a serious application that uses that approach.
(And the energy around Electron suggests that developer demand on desktop is mostly at the higher level of using web technologies to develop apps rather than the lower level of embedding rendering engines into native apps.)
But perhaps I misunderstand the point you were making! Can you elaborate?
It doesn’t, although it might do so in an initial prototype.
Firefox is distributed as the combination of a Gecko XUL runtime (libxul, other shared libraries, and non-browser-specific resources like those in toolkit/) plus a Firefox XUL application (mostly just the files in [Contents/Resources/]browser/, plus the “firefox” stub executable that loads Gecko and points it at a XUL application).
A XUL application that wants to reuse a Firefox distribution only needs its runtime and executable (along with a script/shortcut/executable that invokes the Firefox executable with an –app flag pointing at the appropriate application.ini file). It doesn’t need any of the Firefox front-end implementation.
The only possible exception to that is devtools, which are non-browser-specific but live in the Firefox application for complex reasons that are explained in bug 1244163.
Those are important while developing an app and might also be useful when distributing testing versions, although they’re probably not worth including in a stable release.
I’m not entirely sure. Unlike on desktop, on mobile there’s more interest in building native apps that embed rendering engines (for content-heavy apps like Facebook, Twitter, and Flipboard).
Nevertheless, there’s also some interest in building “hybrid apps,” whose interfaces are mostly or entirely implemented using web technologies. Those generally use frameworks like Cordova and Crosswalk, but there are some bespoke solutions (and semi-web-tech alternatives like React Native are also gaining steam).
GeckoView can potentially address both of those broad categories of use cases, although the former seems to me to be both juicier and lower-hanging fruit. It’s the one I would target initially.
I mean building an application which embeds Gecko, as opposed to runs on Firefox (Firefox being an application in its own right). Like using Electron or Android’s WebView which embed WebKit/Blink.
If you have to check your application into mozilla-central/a fork of mozilla-central or use Firefox to run your application, that doesn’t sound like “embedding” Gecko.
This sounds great! It also sounds a lot like XULRunner, which I thought was deprecated. What’s the difference between this and XULRunner?
Maybe this is semantics but if a “Firefox distribution” doesn’t include the Firefox “XUL application” then in my book it isn’t Firefox. But whatever it’s called, is there somewhere I can download a build of this non-Firefox Firefox distribution (like I can with Electron and could with XULRunner), or instructions on how to create my own build of Firefox without Firefox?
Basically what I’m looking for (and what I assume would also be useful for the Browser Futures team) is something which allows me to create browser chrome, ideally in HTML, and use Gecko to render web content. But without having to fork the whole of mozilla-central or bundle the whole of Firefox with my application in order to do that.
On desktop Electron does this. On mobile Android’s WebView does this (albeit without the HTML chrome part). Mozilla Chromeless, XULRunner, mozApps and B2G all used to let me do this, but no longer exist.
The terminology may be obfuscating our underlying agreement here.
For me, embedding Gecko means linking a native application (C/C++/Objective-C on desktop, Java on Android) to a Gecko library. A framework for doing so is an embedding framework, and an API that Gecko exposes for such applications is an embedding API.
By this definition, Firefox embeds Gecko (although the two are tightly coupled, and the distinction between them can be fuzzy), Electron embeds Blink (using the Brightray embedding framework—although arguably it’s just a static library that exposes an embedding API), and an Android app that uses WebView is embedding WebKit via the WebView embedding API.
But “using Electron” to build an app isn’t embedding Blink, and Electron isn’t an embedding framework. Rather, it’s an application framework that provides an application runtime for apps written using web technologies.
I agree that building an app inside mozilla-central (or a clone thereof) doesn’t seem like embedding Gecko. I also agree that using Firefox to run your app isn’t embedding Gecko. The former technically embeds Gecko, but in a way that isn’t obvious. And the latter is using Firefox as an application runtime (just like using Electron to run your app is using it as an application runtime).
More significantly, in my book: it’s difficult to use Gecko and Firefox in these ways. Even the simplest app requires substantial and arcane boilerplate. And the docs are comprehensive but outdated. The platform may be powerful, but it’s hard to use.
XULRunner was a couple of different things, including a framework for embedding Gecko and a runtime for running applications. Although it doesn’t exist anymore as a standalone product, Firefox is implemented as the combination of a XULRunner runtime and a XUL application. So it’s possible to use a Firefox distribution as a XULRunner runtime.
All Firefox distributions are like this. If you open a Firefox installation directory, you’ll see a browser/ subdirectory (Contents/Resources/browser/ on Mac). That directory contains the Firefox XUL application. Almost everything else in the directory is the XULRunner runtime.
And the firefox(.exe) executable is a stub that runs either Firefox (by default) or any other XUL application (if you invoke it with
--app path/to/application.ini).Here are two examples of apps that embed Gecko without Firefox (albeit via a clone of mozilla-central):
https://github.com/mykmelez/graphene-gecko/tree/master/embedding/graphene
https://github.com/mykmelez/gecko/tree/vrbrowser/vrbrowser
That’s exactly what I’m working on now.
I’ve now blogged about it here:
https://mykzilla.org/2017/03/15/introducing-qbrt/
Heart broken 🙁
I’m sorry to hear it, but I hope qbrt can help mend it!
Incidentally, were you using Positron for something in particular? Or perhaps thinking/planning/preparing to use it? The more I understand the potential/actual use cases, the better I’ll be able to support them in qbrt or other solutions.
I just found out about Positron and, as a FF fan, I am sorry to hear it was discontinued. Nevertheless, I think the idea of using a layout engine for client side applications is a decent one.
Too bad that we are tied – by the current nature of Blink and Gecko – to JavaScript and the DOM: I’d rather prefer to have a middle-ware taking care of handling inputs and laying out elements on the screen (with all the neat features found in web pages: texts, math, images, videos, 3D, camera, sound…) in the most efficient manner possible, not necessarily using the web technologies (HTML, JS, node, etc).
In fact, I am sorry that current layout engines are so monolithic that the best parts cannot be separated from the rest and be reused.
Hi LuckyChoices, I’m curious about your suggestion of a “middleware layer” that isn’t necessarily using web technologies!
Are there other technologies that you’re particularly interested in using (f.e. C++, Rust, etc.)? Would a layer that is JS-only (like a Node.js process or the “main” process in Electron) be sufficient/preferable?