21
Oct 12

Having trouble with Lightning 1.8 ?

I have heard a few reports that calendars are not showing after upgrading to Lightning 1.8. I’d really like to get to the root of the problem and find out if this a code regression or something different. If you are having trouble please comment with the following information:

  • Make sure you are using the right version combination: Lightning 1.8 is compatible to Thunderbird 16.
  • Do you have any other addons installed? I’ve heard about some trouble with the “Calendar Tweaks” extension for example.
  • Open Tools → Error Console and tell me about any error messages you see there
  • Are any calendars no longer in the calendar list on the left side?
  • What kinds of calendars do you have? Local? CalDAV? Google Calendar via the Provider? Other?
  • If you are using the Provider for Google Calendar, what version do you have installed?

Update, with a few common issues:

  • If you are using the Calendar Tweaks Extension, make sure to update to version 4.3.
  • If you are using Lightning 1.8 and the Provider for Google Calendar, please make sure you are using Provider version 0.17
  • If you have a virus scanner that quarantines files, please make sure calbasecomps.dll is not quarantined. Reinstalling Lightning might help.

19
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)


04
Dec 10

Lightning 1.0b3pre now with numerous improvements

If you have been using Lightning 1.0b3pre nightlies, you’ve been missing out on a number of fixed bugs and new features. This is because we’ve been concentrating on making Lightning work with trunk (the newest comm-central/mozilla-central code).

Although not finally decided, the next Thunderbird version is likely to be from the more stable comm-1.9.2/mozilla-1.9.2 branch. Therefore we have now backported all relevant patches to the comm-1.9.2 branch, giving you the chance to see what the next version will be like. If you are wondering why this hasn’t happened before, it is important that bugs are fixed on trunk first. Otherwise it may happen that a future version loses features and bugfixes a previous release contained, due to problems while porting the code.

The Calendar Team would really appreciate if you could give this nightly a spin, especially if you are maybe using your own calendar server, or maybe one that is not so common. The earlier you test this version, the more likely it is that the 1.0b3 release will not contain bugs that make it unusable for you.

If you haven’t yet downloaded Lightning 1.0b3pre, make sure you have a copy of Thunderbird 3.1 and get Lightning here. If you encounter any bugs be sure to search first. If you can’t find a matching report then file a new one. Please also note which version of Thunderbird/Lightning you are using.

Note: The list of bugs that were fixed, which includes the new features can be found here.


24
Nov 10

Helpers wanted: Migrating calendar software documentation to the SUMOMO KB

Dear Calendar community,

This Friday between 7am – 2pm PST we are going to begin migrating the Calendar software documentation to the SUMOMO KB – and we need your help!

Helping is really simple. Connect to our IRC server (irc.mozilla.org) and join #calendar-website – for the migration backchannel.

All you need is:

  • An IRC client (or simply click HERE)
  • A support.mozillamessaging.com account, if you don’t have one, create one here
  • Time and patience
  • Lightning installed is a plus
  • What are we going to do?
    We need your help porting over all the existant help articles on wiki.mozilla.org to support.mozillamessaging.com. Many of the articles are outdated, so it would be great if you could help us check all of the steps mentioned are correct then before migration and  This includes updating the screenshots.

    Once all the articles are ported over, we will send a invitation to the localization community to help us with localizing the articles into other languages.

    Thanks in advance!

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


    19
    Mar 10

    Reducing the Calendar bug count

    We (mostly our lead developer Philipp) have done some heavy lifting with our bug database in recent days. During the last month, we waded through hundreds of bug reports (some of those being several years old) to see whether those bugs had been fixed by all the work that we’ve put into Lightning 1.0 beta1.

    The result of this exercise was a reduction of our total open bug count by nearly 18% or in absolute terms, we’ve reduced the number of open bugs by 276 from 1552 to 1276. This chart illustrates our total open bug count from the start of 2010 until mid-March:

    It’s important to note that not every bug in our database is a real program error. Our bug list also contains lot of enhancement request, project management issues and enhancement requests. Basically everything that comes up in our project that needs to be tracked somehow is entered in our bug database, so that it can be easily tracked.


    11
    Feb 10

    Automated Testing For Lightning!

    When Standard8, Dmose and others on the Thunderbird team started using Mozmill for their test automation, we watched with envy and discussed how awesome it would be to do something similar for the Calendar Project.

    But there were huge technical roadblocks in the way: could Mozmill automate the XBL-heavy calendar user interface? How reliable would any such automation be due to the way the views were drawn on the screen? How much time would it take someone to do it? None of us had the time or bandwidth to figure it out, so Philipp and I proposed it as a Google Summer of Code project and hoped that some brave soul would choose to volunteer for our project.

    The brave soul that answered was Merike Sell, our Estonian localizer. She proved herself an incredibly skilled hacker, finding ways to make these tests work reliably on the Lightning UI across Windows, Linux, and Mac operating systems. She’s even created a complete shared module of calendar utility functions to make it much easier for anyone to add new tests in the future.

    To give you an idea of what types of automatic testing she completed, we have the following tests checked in to calendar/test/mozmill.

    • Event Creation, Verification of Events in all Calendar Views
    • Event Dialog Input Testing, including UTF-8 Input testing
    • Task Dialog Input Testing
    • Task Pane View testing
    • Today Pane Testing
    • Recurring event testing for Daily, Weekly, Monthly, and Yearly recurrences
    • Recurring events are displayed properly in horizontal views
    • Extremely detailed Timezone tests to check for the most common timezone bugs

    Underlying these tests are a basic set of APIs in the shared module testCalendarUtils.js. These APIs can help you do everything from fill in an event dialog to verify that an event is in the correct location on the screen in each view. Merike has written some excellent documentation for the API as well.

    We’d like to thank both Frank Hecker and the Mozilla Foundation as well as David Ascher and Mozilla Messaging for making this possible. And we’d like to thank and congratulate Merike on a job well done. She braved through completely uncharted waters, found a dozen Mozmill bugs and created the first complete set of calendar automated tests in the history of our project.

    Thanks Merike!


    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.


    17
    Jul 09

    Automating Calendar Testing

    As Simon noted, our esteemed Estonian localizer, Merike Sell, is working on automating testing for the Calendar Project. Specifically, she is writing Mozmill tests for Lightning.

    Mozmill is a new UI automation tool for the Mozilla Platform. Mozmill can run either as an extension or as a command-line tool. So, once Merike finishes her tests, we will begin running these via command line, and having them automatically report their results either to the Calendar Tinderbox or some place else (It’s up to the team).

    The first step is to automate the basic smoke tests that we would normally run on a lightning build to be sure that everything is functioning properly. After that, she will move on to writing tests for more complicated scenarios such as recurring events, meeting appointments, and timezones so that we can be certain those critical areas are free from regressions.

    We hope that Merike’s valiant attempts to tame the uncharted jungle of calendar test automation will help others to follow in her path. Her tests are stellar examples of Mozmill tests, and they create a perfect starting point for anyone who would like to learn how to write these types of tests. We are looking forward to a great summer of automation.


    17
    Jul 09

    Donations update – How we spend our money

    It’s been three months since I last posted a donations update. And it’s more than time to update our community on the current state of things, because two exciting things have happened or are about to happen.

    1. Back in April we had accumulated roughly 1150$ of donations and we were heavily contemplating what to do with it. At the same time, a long-term localization contributor, Merike Sell, offered to create an automated testing framework for the calendar applications as part of Google’s Summer of Code. Unfortunately the project was not accepted (only a few of the dozens of worthy projects were accepted by Google), but the offer was too good to let it slip.

      So we decided to use our money to fund Merike’s project outside of Google’s summer of code. Unfortunately our money was not enough to fund Merike for the three months period, but David Ascher (CEO of Mozilla Messaging) graciously agreed to cover the remaining 3350$.

      Merike is already hard at work. You can watch her progress in Bug 500469. Her mentor, Clint Talbert, will post an introductory posting explaining the overall goal of her project. And hopefully Merike will post here as well with a short introductory post and a status update once in a while.

    2. The mozilla.org add-ons site has finally introduced the possibility to ask for donations (or contributions as they call them) directly on the add-on page of each participating add-on. The Calendar Project to participate in this program in the hope of increasing its donations through this avenue. Let me state clearly that these donations/contributions will be optional.

    Let me close by aying “thank you” to everybody who has donated to the Calendar Project so far and to everyone who is planning on doing this in the future. As you can see, these donations can really do some good, so donate now!


    26
    Jan 09

    Calendar Community Testday On Thursday, January 29

    The next test day will be held on Thursday, January 29th. After some code consolidation in the user interface (navigation bar and calendar views) and the introduction of a new preference driven calendar registration, we suggest that you try Litmus test cases and some ad-hoc testing to find regressions in any part of Sunbird or Lightning 1.0pre.

    How to test the new preference driven calendar registration:

    This can be done by updating older profiles from versions 0.5, 0.7 or 0.9. After an update with the latest 1.0pre build all the old calendar preferences (name, color, read-only state, …) should be the same as before. The calendar registration should also be checked with different providers (local calendars, CalDAV, Google, WCAP).

    Please backup your profiles before testing as described on the Test Day wiki page.

    There are also some fixed tb-integration bugs that need to be verified. You simply have to add a comment to the bug report stating what version and operating system you used while verifying the bug fixed.

    Join us in the #calendar-qa IRC channel on Thursday. All the information on the testday is on our usual Test Day wiki page.

    Hope to see you in #calendar-qa!

    Calendar QA Team