Jul 12

Please Test: Print Support in Lightning 1.7b3

Hello Folks, I have a favor to ask.

Update 3: Lightning 1.7b2 contained an error related to printing that has been fixed in 1.7b3, which I have uploaded on 2012-07-29. Please update before testing!

Among some other things, print support has been broken in the nightly builds since about May, when Mozilla did some changes in the XPConnect layer. The effect of these changes were that we can no longer use e4x, a standard to make use of XML directly in Javascript. I have taken care of most of the fixes, but the one bug that has been outstanding a bit longer was the one to fix print support.

I took the chance to revamp the internals of the print layouts to make it easier to extend them. This opens up more possibilities to extend print support in an extension. The problem is now that we needed to land this directly on the beta channel so that print support is not broken in the 1.7 release.

I have just uploaded a new beta containing the patch, so please take a moment to test it with the Thunderbird 15 beta. These areas need testing:

  • All print layouts: List View, Monthly Grid, Weekly Planner
  • All combinations of options, i.e tasks and events, only tasks, only events
  • Make sure the (time) labels on the events in the print preview is correct
  • Different kinds of tasks (with start date, with end date, with both)
  • All importers and exporters (ICS export, HTML export, …)

For testing you will need Thunderbird 15 beta and Lightning 1.7b2. For Lightning, you will get automatic updates if you are currently using Lightning 1.7b1 or 1.7b2 If you haven’t downloaded a Lightning beta yet, be sure to open the Developer Channel box at the bottom of the page.

Update: You will also need a new copy of the Provider for Google Calendar, if you are using it. Get it here.

Update 2: Lighting 1.7b2 contains an error related to printing that will not show the print view.


Jan 11

Dear Link Spammers, you can stop spamming now!

Hello Folks,

Just a minor change, hopefully it works as expected! I have found out how to modify the blog to remove the URL field when commenting. Adding spam urls to the comment text will still cause the junk filter to react, so we should be safe.

I hope this will cut down the amount of spam on the calendar blog, if not immediately then maybe in the long run.

Dec 10

Updating holiday calendars

We’re in a desperate need for updated holiday calendars, as many have not yet been updated for 2011.

In detail, we’re looking for calendars for the following countries / locales:

  • Basque
  • Belgium (Dutch)
  • Chile
  • Greece
  • Kazakhstan
  • Lebanon
  • Malta
  • Namibia
  • Puerto Rico
  • Singapore (Submitted, but not reviewed yet.)
  • Sri Lanka
  • Switzerland
  • Turkey (Submitted, but not reviewed yet.)

All of these local calendars will expire when they’re not updated and will have to be removed if we don’t find a contributor who can support them.

If you would like to help, please follow these steps:

Once complete, we can update the calendar file on the website as soon as possible.

Thanks in advance!

If you need further information about this process, don’t hesitate to contact us in the #calendar-website channel on irc.mozilla.org or calendar@mozilla-uk.org

–The calendar website team
(Tobias Markus, Tom Ellins, Jan Bambach)

Apr 10

Cached Calendar Database Upgrade

Hello Folks

We recently fixed bug 479867 which does a quite invasive change to the database schema. The change itself is simple, but since the existing cached calendars need to be migrated in some form, it got quite tricky.

If you are having trouble with the upgrade, please leave a comment here or file a bug. Things you should do first:

  • Enable calendar.debug.log and check for any storage related messages
  • Remove or rename $PROFILE/calendar-data/cache.sqlite
    The cache is automatically regenerated if it does not exist. To find your profile,
    see this page

Please also describe what kind of events you have in your calendar (lots of events? more recurring events, or more single events? Accepted invitations?), what kind of calendar you are caching (caldav, google calendar, ics) and what error message you are getting.

Dec 09

Release Status – Lightning for Thunderbird 3

I’d like to give you guys another update of how our release process is going, especially since Thunderbird 3.0 is now released and we are not ready yet. To take the interesting details up front, I believe we will be able to release rc1 before Christmas. If no urgent issues show up, we will be able to release the 1.0b1 final for or shortly after Christmas. This release will be compatible with Thunderbird 3.0.

From the product point of view, we are ready. We have all the patches in that we think should belong in 1.0b1rc1. Therefore, the nightly builds should be of the same quality that the release candidate 1 will be.

If you cannot do without Thunderbird 3 and are brave enough to try pre-release grade builds, I’d suggest to take a look at our nightly builds. Be sure to do backups first though! Otherwise please bear with us until we have the beta released and stay with Thunderbird 2 in the meanwhile.

From the release engineering point of view, we are constantly running into Problems. I believe the biggest and most unsolvable problem is that I am in a different timezone than Mozilla Messaging’s release engineering, which means there is only a small timeframe where we can communicate about build issues. All other problems are at least solvable, but need some time to identify and find a solution for. Each attempt for building the release candidate has a build number. Let me summarize what happened during our builds:

Various problems before we could start building, including but not limited to missing access and l10n problems.
Build system problems caused first mac/win32 to fail, then linux/mac to fail, and so on. The reason was that a script only used for calendar was called with the wrong path, but only in the rare case that the build is called with the packaging target needed for the release.
We noticed, that Thunderbird 3.0 has some storage changes that are not on the normal 1.9.1 branches, so we needed to make sure the calendar release branch is based off of the Thunderbird 3.0 release branch.
Lightning version number was incorrect, the version bump script doesn’t take care of install.rdf changes
Mac’s lightning.xpi is not universal, which means we need to respin. Also checked in some last minute caldav and wcap patches we probably would have taken for rc2 anyway.
Normal Sunbird builds succeeded, localization repack failed. I hope gozer knows why this is happening and can tell us tomorrow.

Another “problem” is that gozer needs to trigger and upload the Lightning builds manually, which also takes extra time once for each build. I do hope we can finish off the last problems soon. I’d like to again note that next time around this process will be much shorter. We don’t need to fix the small build system issues, all we need to do is update the release config and trigger a build.

Nov 09

Getting a Database Error in your Nightly?

This post is directed towards those of you who are regularly using nightly builds.

Due to some problems in the upgrader code for the local storage calendar, some of you might be getting an error like:

Error updating timezones: Error: mozIStorageStatement::step() returned
an error
DB Error no such column: recurrence_id_tz

To be more specific, this should affect all nightly users that have used a build after 2009-11-07. Fortunately, we have fixed this issue in bug 529853, but this won’t save nightly users that already have a broken profile. Luckily, its quite easy to fix the problem manually.

I have created an extension that can be used detect if your profile is broken and also to repair it. For more information, please see bug 529853.

Update:The first version of the extension didn’t properly update the cached calendar. If you are still experiencing problems, try the new version, I’ve updated the above link

Aug 09

Merike’s developer comments: Writing smoketests for Calendar

In February 2008 I wasn’t even a user of Lightning yet as it becomes obvious from looking at my home calendar. Four months later I was researching how to translate it so I could have Thunderbird and Lightning in the same language because an Estonian localization didn’t exist.
A year later being familiar with the localization side of Mozilla and using Lightning regularly the option to write tests for calendar looked really appealing when I noticed it in the wiki. In April I found myself participating in the testday for Mozmill 1.1. (There’s another one coming where you could participate by the way!)

Now that I’ve written smoketests for bug #500469 I find Mozmill relatively similar to Selenium as I expected. Both of these tools test user interface functionality and therefore the basic three types of steps are common to both:

  • Locating elements to act on
  • Specifying actions to be done
  • Checking the results

Element location in a Mozilla application can be done either by using Mozmill’s inspector which gives you a ready to use locator or with the help of DOM inspector if you need to access an element that is further down in the hierarchy of UI elements than what Mozmill’s inspector gives you. Locators in Lightning are quite long but mostly relatively easily accessible. There are exceptions to this though: bug #505336 being an example of an element that is fighting against automation.

As UI responsiveness is always slower than script speed pauses between test actions are essential to let UI load properly. Failing to do that can result in an otherwise fine-looking test not working and once in a while I’m still able to forget that despite of knowing it. There are also some inconsistencies between platforms support of Mozmill which made it impossible to stick to the Linux environment I mostly use but it also gives both the Mozmill and Calendar development version stress on both platforms which can only make these more bulletproof.

Result checking is the most important part of functional tests even if running a test without any asserts can reveal some of the bugs too. This is also the part of Mozmill code that recently reminded me of just how quickly Mozmill is developed. I was looking for a way to assert that a certain element is not hidden and found a assertPropertyNotExist function by scrolling through the available methods on Google Code. This seemed like a good way to make sure that there’s no hidden attribute attached to an element. To my surprise the first call to this method caused a failure which stated that there’s no such function. It had been added only a couple of hours earlier and the version installed didn’t have it yet!

Active development of Mozmill and fantastic people on both the #qa and #calendar IRC channels make the difference between a person merely checking things out and a new participant in the project. That’s what it takes to get a new person to participate.

Mar 09

Philipp’s Developer Notes: Using JavaScript 1.7 Iterators to simplify code

The list of new features in JavaScript 1.7 have been out for a while but only since the move to Trunk (Gecko 1.9.1 codebase) have we taken a look into it.

The concept of iterators is nothing new, the way they are implemented in JavaScript initially confused me. Consider the following bits of code:

function range(begin, end) {
for (let i = begin; i++; i < end) {
yield i;
let it = range(10, 20);

What is this!? A function with a loop that doesn’t return anything and contains a strange statement called yield? Without much reading, my next though was: why does |it| contain anything? Shouldn’t |it| be undefined? The function doesn’t return anything, so why should yield make a difference?

I guess the return “issue” just takes a bit getting used to. Most iterator functions are very small, so |yield| should be easy to spot. Now I’d like you to see why this strange construct is indeed very useful. Consider this (old) bit of code. It was used when turning an ICS string into an item:

for (var attprop = icalcomp.getFirstProperty("ATTENDEE");
attprop = icalcomp.getNextProperty("ATTENDEE")) {
var att = new CalAttendee();
att.icalProperty = attprop;

A multi-line for() looks very cumbersome even aside from the fact that the different line lengths make it harder to read, don’t you think? Now lets see what magic we can do with iterators:

for (let attprop in cal.ical.propertyIterator(icalcomp, "ATTENDEE")) {
let att = cal.createAttendee();
att.icalProperty = attprop;

You’ll notice a few things changed. The loop now uses the newly introduced property iterator and only one line (even though its a bit longer). You’ll also see use of the new “cal” namespace, which probably deserves its own blog post. While this may look like a minimal change please consider a lot of such for loops are used when turning an ICS string into an item. Also I feel this makes the formerly quite native code pattern (getFirstXXX, getNextXXX) fit more naturaly into JavaScript.

We can go even further, using more language features of JavaScript 1.7. This bit of code used in the same context:

this.mCategories = [];
for (var catprop = icalcomp.getFirstProperty("CATEGORIES");
catprop = icalcomp.getNextProperty("CATEGORIES")) {

Can be compromised into a single line, using iterators as described above and array comprehensions:

this.mCategories = [ catprop.value for (catprop in cal.ical.propertyIterator(icalcomp, "CATEGORIES")) ];

I’ll admit this line is a bit long. I have found no sensible way to split it, comments welcome. You’re surely interested how to create something that can be used as an iterator so that you can use it in your own code. I’ll give you the source for the above cal.ical.propertyIterator:

function cal_ical_propertyIterator(aComponent, aProperty) {
return {
__iterator__: function icalPropertyIterator(aWantKeys) {
cal.ASSERT(aWantKeys, "Please use for() on the property iterator");
let propertyName = (aProperty || "ANY");
for (let prop = aComponent.getFirstProperty(propertyName);
prop = aComponent.getNextProperty(propertyName)) {
yield prop;

Looks quite similar to the old code, doesn’t it? The concept is quite simple. We return an object that implements the special __iterator__ method. This is where we put the old loop code. Then we “yield” the value that should be availibe in our new loop code. The argument aWantKeys differentiates if only the key is wanted or not. If the iterator is used in a for() loop, then aWantKeys is true. If it is used in a for each() loop, then the argument is false.

for (let key in myIterator()) {
// A for(...in..) loop goes through all keys in the array or iterator.
// The aWantKeys argument is true.
for each (let [key, value] in myIterator()) {
// Standard object iterators return an array with key and value
// when aWantKeys is false.
for each (let value in myOtherIterator()) {
// Some iterators prefer only returning the value in this case.

The above code is of course only an example. You are of course free to return anything you want in your iterator.

Note that you can use the __iterator__ on any object, it doesn’t have to be an object that has no other properties.

function calPropertyBag() {
this.mData = {};
calPropertyBag.prototype = {
mData: null,
__iterator__: function cpb_iterator(aWantKeys) {
for (let key in this.mData) {
yield (aWantKeys ? key : [key, this.mData[key]]);
/* In this case, instead of the above you can shorten this iterator to:
return Iterator(this.mData, aWantKeys);
/* Also implement other methods like setProperty,deleteProperty,... */

See how this basic property bag now has an iterator that can be used directly? Without the iterator, using this code:

var bag = new calPropertyBag();
for (let key in bag) {
dump("Key: " + key + "n");

Would give you all keys in the object: mData, setProperty, deleteProperty and so on. With the new iterator, the above code would rather give you the actual properties in the bag, since the __iterator__ yields all keys in this.mData.

I hope this inspires you, regardless of if you are working on a Sunbird/Lightning extension, or any other piece of Javascript code for that matter. Please do feel free to correct me, I’m quite new to these features so not everything might be 100% correct.

If I come across more new langauges features, I’ll keep you posted!

Jul 08

Privacy alert: Google calendar may display real names of other Google mail users

As discovered by SecuriTeam it’s possible to discover the real name behind a Google mail addresings in web forums, mailing lists or newsgroups. It could also give spammers the ability to send you more targeted advertisements.

More details are in the relavnt SecuriTeam blog post. Since a lot of our users use Google Calendar, I thought I might pass this along.