The big Thunderbird migrations and qbrt

R Kent James kent at
Fri Mar 17 19:13:29 UTC 2017

Myk Melez, who has been pushing various ideas for embedded Gecko, has a 
new twist on his plans:

Essentially this "reuses an existing Gecko runtime (and its existing 
APIs) while simplifying the process of developing and packaging a 
desktop app using web technologies." He previously had tried to develop 
a gecko-flavored version of Electron called Positron, but abandoned 
that. The main difference is that Positron tried to duplicate the 
existing Electron APIs, while qbrt simply packages the existing Gecko 
APIs into a desktop app package, relying on XPCOM and web apis to 
provide the equivalent to the Electron APIs.

Thunderbird essentially faces three relatively separate challenges in 
converting its backend away from the current binary recompile of 
Firefox: C++->JS, XUL->HTML, and XPCOM->SomethingElse. qbrt AFAIUI uses 
a stock Firefox compile, so any C++ used by Thunderbird would need to be 
converted to JS. But the other two conversions could wait. So this could 
serve as an interesting intermediate step to conversion. We could even 
hope that build related issues would be vastly simplified if we only 
needed to package non-binary files.

Having spent the last year doing C++->JS conversions in ExQuilla, I have 
pretty good metrics on how difficult that is. Scaling to all of 
Thunderbird C++, it represents about 10 person-years of effort. That is 
a much more imaginable amount of effort than the roughly three times 
that which would be required to do a complete conversion of all three 

There is still a lot of uncertainty about the direction of Gecko. The 
platform team seems absolutely determined to rip anything out of Gecko 
that is not directly used by either Firefox or required by 
WebExtensions. It's hard to believe that there are not going to be some 
gotchas in the core C++ that we will need to work around. Perhaps it 
would be possible to have an EmbeddedApps branch of mozilla-central that 
would not be difficult to maintain. Then there is the moving target of 
what is still left of XUL and XPCOM as they move to eventually eliminate 
those. Challenges.

Still, we need to do something. I think that we should seriously 
considering allying with Myk and qbrt to try to move forward a 
gecko-based desktop app environment. With enough partners, that might 
help convince the platform team that this is worth supporting, at least 


More information about the tb-planning mailing list