Thunderbird as a Web App revisited

Ben Bucksch ben.bucksch at
Sun Dec 20 12:14:29 UTC 2015

Robert Kaiser wrote on 20.12.2015 03:51:
> Ben Bucksch schrieb:
>> That runtime would need some features that a normal webbrowser does not
>> have. The absolute minimum that comes to mind is opening TCP sockets, to
>> allow IMAP/POP3 without proxying, and opening/saving files (even if only
>> in a certain directory on disk), to store emails persistently locally.
>> Probably I'm missing a few other things.
> Both exist in Gecko and have been implemented for Firefox OS (though 
> file access through DeviceStorage is somewhat awkward). They may not 
> be fully implemented on desktop platforms and/or enabled on Firefox 
> but that is a gap that Mozilla wants to close from all I know.

I know. There are several potential runtimes:
* XULRunner (without using XUL, and XPCOM only for those few APIs I 
* FirefoxOS
* GeckoView in Android (offshoot of Fennec), with adding custom JS APIs
* NW using node.js

Either way, I would ship the runtime with the app, like Thunderbird 
today ships Gecko with the EXE, and install and start it all together in 
one go. Simply to make it easy for end users.

And also to avoid having to deal with 3 different HTML renderers in 15 
different versions each (particularly on Android, where people still use 
Android 4.0 etc.), and to official support them all. They still have 
minor differences, and that's a major hassle in web dev. That would hold 
us back.


To answer Paul directly: While technically possible to ship a server 
with the app, there's no point in doing it either. It's just a further 
indirection, so slower. And also additional trouble: if one of them 
crashes or is closed, you need to ensure that the other is closed, too. 
That's not as easy a problem as it sound, if you want it to work in case 
of error situations. It's easier to build these few APIs directly into 
the JS API of the runtime.


More information about the tb-planning mailing list