Lightning trunk is back on track!

For those of you using a Thunderbird 3.3 Alpha version or later, we have great news! I have finally managed to fix bug 591744, which was the last of the many bugs that had to be fixed to recover from the major changes to the mozilla-central platform.

If you would like to give it a try, you will need either a nightly or alpha version of Thunderbird, together with the nightly version of Lightning. You can get these using the following links:

Update: As noted in the comments below, the trunk versions of Lightning also work with the following beta versions of SeaMonkey:

* To avoid misunderstandings, even though it is named 1.1a1pre, this does not mean we have release 1.0 yet! Lightning on trunk (labeled 1.1a1pre) uses a different Mozilla platform than Lightning from the 1.9.2 branch (labeled 1.0b3pre). We have chosen differing version numbers to make that difference obvious.


  1. Hi,
    works well!
    Even with the conversation add-on.
    Really cool.

  2. Jesper Kristensen

    Thank you. Mainly for telling what these different version numbers of lightning means. That has been a great mystery for very long.
    But still I am not quite sure what 1.0b3pre on the 1.9.2 branch is for. Are you planning to release an update of Lightning for Thunderbird 3.1.x? Are you building it in case the Thunderbird devs chooses to release a second Thunderbird version on the 1.9.2 branch (Thunderbird 3.2)?

  3. Jesper, I’ll try to make this more clear. I have extended the wording on and linked this page from the main page.
    Please let me know if something is unclear.

  4. Does the Lightning Nightly Updater still work ion trunk? The version of LNU I was using on Lanikai doesn’t work anymore and the add-on manager doesn’t find any updates.

  5. My previous comment was not posted, and there was no message that it was “successfully submitted and is being moderated”. This is a frustrating situation. Please provide some feedback when we post comments.

  6. Peter, I’ve emailed Olive to update LNU. Sorry I haven’t done this earlier. If you want to hack it in until then, in the content/overlay.js line 106, change the version number to 3.3
    I’ll see what I can do about the blog comments, I don’t really have much influence on that though.

  7. Philipp: Thanks for your response and action (e-mailing Olive to update LNU). A few additional issues:
    – I think the “Provider for Google Calendar” add-on *might* also not be working (despite maxver bump hack). Lightning doesn’t display my Google Contacts’ birthdays (although that has always been tricky to set-up and an unreliable feature).
    – When creating a new calendar, there is now a new “Format” called “Google Calendar”. There is no tool-tip, online help, bug report, or an indication in the dialog window what *type* of calendar it should be (Google offers many types: (1) Calendar-ID (2) ical (3) html (4) xml (5) CalDav). Only by accident did I discover that it’s the CalDav url that works (BTW: the CalDav url is not given in Google’s Calendar Settings – so it’s an “insider” setting). Perhaps Lightning could just ask for the “calendar-ID” (which is given in the Google calendar settings), and auto insert that into the CalDav url (

  8. And these trunk versions of Lightning and gdata-provider work also with the following beta versions of SeaMonkey:SeaMonkey 2.1b2, soon to be released — when it is, it will be announced on the SeaMonkey news page;SeaMonkey 2.1b3pre nightly (en-US);SeaMonkey 2.1b3pre nightly (other languages).

  9. @Peter Lairo: I have always used the iCal link to Google calendars, and it works for me. The same URL can also be declared as “iCal (ICS)” if you don’t need read-write access.

  10. @Tony Mechelynck: Perhaps you’re right. But Google gives a different URL for “iCal” ( I was able to get it working with CalDav by updating to a more recent version of Lightning (via Lightning Nightly Updater).

  11. Ah fsck, they really changed the ical url. I’m probably not subscribed to the right blogs to notice such changes. Please file a bug to fix detection. The XML url should still work.
    There is a bug to further modify the new calendar wizard, but I’d like to get it fixed for both caldav and the provider, so we can reuse code. This is a bit further down the line of things to do though.