Monthly Archives: August 2009

Lightning / Sunbird — 8 Comments
24
Aug 09

[August 24, 2009] Lightning/Sunbird Status Update

More than one month has gone by without a status update. Obviously it’s vacation time :-)) We’re hard at work to finally get our next release out of the door for Lightning and Sunbird. More on that in a separate post. Over the last six weeks we have fixed 22 bugs, which are listed below.

  • 328216: It is not possible to assign duration to a task
  • 378951: [Mac] non-functional button in About Sunbird dialog
  • 411849: Default date for add New Task is current day rather than the selected day
  • 430090: Collapsed state of Today pane is not remembered when dragging the splitter
  • 445304: Today-pane: width should be set mode-dependently
  • 459381: Calendar and task tabs should be persistent
  • 471860: Use .trim*() in Calendar
  • 483643: Strict JavaScript warnings “reference to undefined property”
  • 500718: (scalability) useless refresh of unchanged calendars in onCalendarAdded/-Removed
  • 501402: Day View not updated correctly after deleting multiple events
  • 501613: Croatia holidays
  • 506461: Change the menupopup id in messenger-overlay-toolbar.xul
  • 506608: View, task list, and toolbar broken after startup
  • 507105: Task list doesn’t update correctly when adding/removing calendars
  • 507170: Removing calendar breaks unifinder
  • 507700: WARNING: Illegal character in window name calendar-properties-dialog
  • 508295: Task list: creating new task via double click or context menu entry fails
  • 509335: Make use of zoom controls for calendar views
  • 509345: US Holidays file uses inconsistent categories
  • 509405: Calendar builder tinderboxen down? starting 2009-08-10
  • 509936: Warning: undeclared variable in minimonth.xml
  • 510499: Correcting grammar on Sunbird homepage

As always, our thanks go to all developers, contributors, localizers, testers, and supporters that have made this possible.

Lightning / QA / Sunbird / Technical — Comments Off on Merike’s developer comments: Writing smoketests for Calendar
06
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.

Sunbird — 15 Comments
02
Aug 09

How to Save Sunbird

Since the last blog post, many people have asked what can be done to keep Sunbird alive. I’d like to attempt to answer this question, and also tell you how to bring Sunbird forward (i.e attracting new users).

What’s needed to keep Sunbird alive

On the development side, whenever a Lightning bug is fixed that touches shared code, extra testing and possibly some coding is needed to make sure that the bug is also fixed in Sunbird. In most cases no additional work is necessary, but once in a while Sunbird acts a bit differently. Similarly, when a new feature is added to Lightning, some extra work may be needed to make sure Sunbird can also benefit from it.

Extra testing is also needed for Sunbird. This includes regular testing of nightly builds and writing or adapting automated tests to work with Sunbird. Also some triage work needs to be done. When a bug is filed and there is no note if the bug relates to Sunbird or Lightning, the reporter needs to be asked just this question. Appropriate bugs should then be moved into the Sunbird Only component, which should be looked after in case of duplicate or obsolete bugs.

Some release engineering work also needs to be done when nearing a release. This includes configuring the automatic update servers and moving around builds on the ftp servers.

Note however you don’t necessarily have to do all of this on your own. Depending on how many people are interested in actively working on Sunbird it’s quite possible that you can split the work similar to how we’ve been doing it (backend, frontend development, user experience, release engineering, testing).

Sunbird’s possible future vision

What Sunbird needs is a vision of its own. That means, that new Lightning features should no longer be incorporated into Sunbird by default. Instead Sunbird needs to get its own identity to attract new users. If you have experience with user interfaces, Sunbird could use your help to create a new and innovative way for users to manage their appointments.

A vision we have come up with and other users have also brought up is to make Lightning modify Thunderbird so far that starting from a new profile gives you the option of either a calendar or mail account (or both). If you choose Calendar, then you will be presented with only calendar relevant UI (i.e similar to what Sunbird is today). You will not be bothered with mail features unless you need them (i.e you want to invite attendees and send invitations to them). This would have the benefit of shared features like the address book being available without much extra work.

If you would like to save Sunbird, please drop me an email and I’ll help you get started. Please be sure to tell me what area you’d like to work on and if I can forward your Email address to other people interested in helping with Sunbird.