[Maildev] thunderbird near term focus

Magnus Melin mkmelin+mozilla at iki.fi
Thu Oct 25 08:42:28 EDT 2018

Below I've noted down some work packages to concretize my thoughts on 
where I think we should be putting resources into in the near future. We 
will make more detailed plans as we go, but as a starting point. 
Comments welcome! For commenting, please quote only the relevant item 
(you know, select+reply).

Thunderbird will be bringing on more staff in the near future, so these 
are all items that could end up in someone's deliverables soon. Stay 
tuned for an official job posting! If you already notice something you'd 
be the perfect candidate for, please send a cover letter and CV to 
jobs at thunderbird.net



    Address UI slowness

  * analyze UI slowness to and identify pain points
  * create tests to automate measuring of UI operational performance
  * perform architectural changes to support smoother operations
  * rewrites leveraging web technologies (especially moving load to
    workers where possible)
  * multi-process Thunderbird, using Frame scripts etc.

UI jank of various kinds is a top complaint from our users. We should 
pinpoint the causes of these and fix them. I think having automated 
tests so that we can measure progress would be important to see things 
go in the right direction.

    Integration improvements

  * better Gmail support
      o and get started with a global storage implementation (with
        folders being labels, like in Gmail)
      o of our users a great deal of them use Gmail, so it makes sense
        for us to improve supporting their quirks
  * better notifications (system integrated)
      o our notifications are currently less useful than they could be.
        There was earlier work to unify the implementation across
        platforms, but this was not completely finished. We can likely
        drop a lot of platform dependent implementations and unify the
        "content" production logic, and then send /that/ off to the OS
        specific notification handling.
  * improved .ics handling
      o handle inline event display better (and prettier)
      o .ics system integration (click to handle, from inside the
        application, and OS handling of .ics)
      o improvements to invites (and at the easy cases for free text),
        to see the new event details in context before taking action
          + this is an area where we can shine in privacy

    Finish rewriting nsMsgSend

  * finishing Joshua's sending rework (with ultimate goal of removing
      o see
        and bug 1211292
      o verify, complete and add tests to for converting MIME tree to an
        RFC 822 blob
      o implement building the MIME tree
      o implement support for the actual sending steps (via

If we ever going to be get rid of libmime, this is the first step 
required. Once we have the putting-together-a-messsage functionality 
done, the next step would be using JSMime for body display and 
ultimately remove it altogether.

    Rewrite and improve mail filters

  * move filtering to async JavaScript implementation (filtering
    currently done synchronously in C++)
  * make filtering contextual (currently per server, we want it to be
    potentially global, or potentially just applying to a single folder)
  * add ability for pre-filter MIME processing, so that filtering can
    work on a message representation instead of on the raw MIME
  * investigate interaction with servers:
      o Sieve scripts through filtering - ManageSieve protocol support
      o interaction with Google filters (through gdata api)

Filters appears to be very well suited for a JavaScript rewrite. The 
async nature that would be preferable is much more easily done in 
JavaScript than in C++. Our filter code is very well tested too, so it's 
easy to tests you didn't break it all. To address the problems of not 
having filters on mobile (since we have no mobile client), make sure 
filtering can sync up to the server. Assuming it's a server that have an 
API for filtering - but without that we help our users. Likely to also 
help remove some UI slowness.

    Protocol rewrites using web technology

  * mail protocol rewrites into JavaScript (maybe SMTP first) and
    integration in Thunderbird
      o starting with NNTP might also be an option as it is a simple
        protocol and in general self contained
      o see http://emailjs.org/ and

There are some JavaScript implementations of IMAP and SMTP at least (as 
used in Gaia email), but they are missing features we need. Due to great 
advances in JavaScript the last years, the libraries need modernization 
to use async and Promises, and other fixes. But they could be a good 
start. If we could implement an incoming mail server account type to use 
the new implementation, then hopefully we can iterate from there to get 
something that works well enough for general consumption.

    Better, easier encryption with decent UX

  * improve the out-of-the-box encryption experience regarding encryption
  * encryption it should just work. we can't expect the end user to know
    how to renew a certificate, and it's questionable if they should be
    expected to know they have a certificate at all.
  * remove tech jargon and fix wrong/confusing messages, etc.
      o usability study attached to
        https://bugzilla.mozilla.org/show_bug.cgi?id=1243449 lists a
        bunch, but there are more :(
  * implement OTR and encrypted chats (bug 954310)

    Adopt best add-on features

  * move best of add-ons into core (but avoid gross hacks)
  * better import/export/access to own data (see ImportExportTools)
  * TNEF support - see "LookOut (fix version)"
  * best parts of Quicktext
      o but probably with a redesigned templating system (based on
        Template literals?)
  * investigate Exchange support, at least for calendar. For mail, you
    can always [try to] convince the administrator to enable imap/pop,
    but for calendar there's no other option.
      o https://github.com/ExchangeCalendar/exchangecalendar (GPL, v3)
          + see if they would be interested in re-licensing it so we can
            ship it?
      o or https://github.com/jobisoft/TbSync ? see also

For the most popular add-on features, it doesn't make a lot of sense to 
keep them as add-ons. Most users don't know about add-ons => won't ever 
find out the feature exist, and many traditional add-ons are not going 
to be updated to be WebExtensions. There is of course the benefit of 
having the maintenance responsibilities distributed, but it would be 
preferable if the (former) add-on authors were to maintain the code 
in-tree, and that way also easily get involved in other areas, as well 
as in fixing actual bugs instead of working around them.

    Automated testing upgrade

  * modernize thunderbird's automated testing
      o mozmill -> marionette?
          + going forwards, or port over old tests too?
      o investigate other alternatives

Mozmill is abandoned since a very long time ago, but is still our main 
testing framework for UI. We should investigate moving to Marionette 
like Firefox, at least for new tests.

    Better support for open formats and structured data

  * CardDAV support integrated
  * WebDAV for filelink
  * vCard rewrite (starting point: rip out nsIMsgVCardService)
      o investigate if there are js libraries we could incorporate
      o vCard 3.0 and 4.0 support needed
      o CardBook (https://gitlab.com/CardBook/CardBook) code supports
        these. Possibly integrate that?
  * support sending and receiving "actions in emails" (see
  * JSON-LD and RDFa Lite support (especially for copy/paste operations)
    for contacts, events and tasks.

Letting the user access their data and do cools things with it while 
preserving privacy is one area where we can shine. Currently the actual 
data "access" is not easy and improving it would easily make for some 
really nice features. To sync contacts to 3rd parties, vCard 3.0 is 
required and we only support vCard 2.0, with code dating back from 
1996(!) (and as you'd imagine, looks like it too).

    The complete Thunderbird package setup

  * solution for complete package (for someone wanting to use
    Thunderbird in an organization and have it "just work")
      o account setup, first run experience: polishing, set up all the
        things you need (mail, calendar, contacts, filelink, chat, and
        encryption?). DNS SRV perhaps?
  * "blessed configurations"
      o perhaps create guides and partner with some providers on how to
        set up a solution for your 100-person company?
      o docker container to deploy?
      o some way for companies to get support (for pay)
          + gate them towards sponsoring features they need too

I think there is a need for officially supported configurations. 
Something the IT admin can point to when his manager asks him "what 
about support"? We have a lot of pieces that can and will work after 
correct setup, but it would be nice if we could point administrators to 
a blessed package they could just set up and not have to worry about all 
the details. Well, there are two different paths: one for 
administrators, and one for end users.

    Calendar improvements

  * Remove use of all calendar XPCOM components and replace them with
    simple JavaScript classes if possible.
  * Make the calendar and tasks tabs self contained, preferably using
    html only
  * Make it possible to completely defer Lightning startup, including
    the alarm service and any other background services
  * Change the Thunderbird UI Integration so that most calendar features
    are only visible once triggered, e.g. user really wants to accept a
    calendar invitation
  * Reduce or eliminate XPCOM dependencies
  * Finish ical.js and remove libical

[^^ This one mostly from Philipp]. Make calendar less reliant on Mozilla 
internals. Figure out how to make ical.js performant enough to let us 
move over to that completely.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/attachments/20181025/4d0d63b7/attachment.html>

More information about the Maildev mailing list