Provider for Google Calendar Postmortem

First of all, I’d like to apologize for not adding in new blog posts once in a while. There have been a few topics I could have written about, but I never got around to it. The consequence is that there will be a few posts in succession now, I hope to be better about this in the future.

In this post, I’d like to tell you a little bit about the changes to the Provider for Google Calendar that have taken place in the last months. With due prior notice, Google has shut down version 1 and version 2 of the Google Calendar API. The previous version of the Provider for Google Calendar, version 0.32, was still using the API v1.

The changes to the API were fairly substantial, so I took the opportunity to rewrite large parts of the Provider to use new JavaScript features and generally make the code more readable. I also added some new features, including:

  • Support for tasks using the Google Tasks API
  • A very user friendly new calendar wizard, no need to enter the XML url.
  • Offline support by default, with no need to disable it.
  • Support for the activity manager, sync progress is now shown in status bar
  • Better (albeit not perfect) support for accepting invitations
  • Allow setting default reminders
  • Compatibility to Postbox 3

As such drastic changes are a common source for regressions, I went through 10 rounds of pre-release testing and got some very helpful input from those who commented on the bug or sent me an email. There would have been substantially more issues without these folks, so thank you very much! In the last round the amount of issues was down to a level where I felt comfortable releasing the Provider to the world.

When I release version 1.0, something inevitable happened: nearly 300,000 users find more issues than 140, so I had to do a few additional releases to fix more major issues. The new API version imposes limits on the number of requests being made, so one of the first issues I had to overcome was gaining more quota. Thanks to the fantastic folks at Google I was able to solve this issue using a combination of code changes to reduce the number of requests and also higher quota limits. Here is a roundup of the other issues:

  • Version 1.0.1
    • Calendars were incorrectly migrated from 0.32 to 1.0
    • Users who disabled cookies could not use the login dialog
    • Attendees added from Hangouts were incorrectly shown
  • Version 1.0.2
    • Added descriptive text to the new calendar wizard to make it easier to understand for users who were used to entering the XML url.
    • Refresh intervals smaller than 30 minutes were prohibited due to quota issues
    • Calendar is no longer refreshed when user is idle
    • Bumped number of results per request from 50 to 1000
    • Various issues w.r.t. showing correct messages on quota or login errors
  • Version 1.0.3
    • Postbox 3 support, which essentially means backwards compatibility to various older Mozilla Platform versions
    • Recurring events no longer disappear when modified
    • Recurring alarms are correctly snoozed.
    • Fixed error “this.mDeferred is null” when login fails
    • Removed lots of debugging messages
    • Back button in new calendar wizard no longer causes double-subscriptions
    • Synchronizing no longer blocks UI thread
    • Calendars no longer get disabled when in offline mode
    • Use application locale when showing OAuth window
    • Fixed an invalid timezone definition for the start time
    • Provider no longer ignores default reminder settings
  • Version 1.0.4
    • Notifications are now correctly sent when modifying events
    • Fixed creating events without an organizer but with attendees
    • Fixed an error in the attendees dialog with “entry.interval is undefined”
    • Correctly create events in UTC timezone
    • Wait for parsing to complete before completing synchronization
    • Fix some internal issues and a compatibility issue with Thunderbird 24
    • Improve invitations handling
    • Google login popup now has a description as to why its required
    • Fixed setting default alarm props on calendars without default alarm
    • Task lists now work for calendar entries without a calendar (regression)
    • Outdated client message shown when using obsolete token

In retrospect, there have been a lot of complaints, but on the other hand a lot of people have noticed how important this addon has become for them. Many have shown their gratitude by sending a donation via the addons page. I hope that version 1.0.4 fixes most of the issues, there are just a few more issues reported. If you continue to experience difficulties, please send me an email or visit the support forum.

 

 

 

This entry was posted on Saturday, February 28th, 2015 at 1:42 pm and is filed under Extensions. You can follow any comments to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

4 comments

  1. Peter Corfield
    March 15, 2015 at 7:55 pm

    Lightning 3.3.3 running with Thunderbird 31.5.0.
    Calendar entry created on a date under GMT with start time 20:00 with weekly repeat shows as 21:00 after start BST, ie displays only in UTC not DST modified local. I see no check box for respecting change to/from DST in setup and clearly the OS adapts to the change automatically. Underlying Google calendar reflects that change but Lightning does not. Will Lightning change the displayed times after the change to BST?

    • Philipp Kewisch
      April 12, 2015 at 8:23 am

      This is likely an error in the Provider for Google Calendar. There is a bug on file and I hope to find a fix soon.

  2. Antony F Heaton
    June 10, 2015 at 1:04 pm

    I have this problem in the GMT/BST time-zone, but I have narrowed the problem. First I created a new Thunderbird local calendar and created a monthly event from 12:00 to 13:00 on 1st January: this was correctly created in the Europe/London time-zone and it still shows as starting at 12:00 while summer time is in force. The same event created in a Google-linked calendar shifts to starting at 13:00 during summer time, though it still shows as 12:00 on Google Calendar when I view it on-line. Although I created the event in Thunderbird as in the Europe/London time-zone, it subsequently shows as GMT/UTC, even after I change it (though, if I acknowledge a reminder, this can remove the time-zone from the Google Calendar entry). However, if I create the event in the Google-linked calendar on 1st May (in summer time), the time shows 12:00 throughout the year and the time-zone shows correctly as Europe/London. This suggests that Provider is confusing GMT/BST with GMT/ITC for events created with zero offset from GMT. It also suggest a work-round for recurring events which start in winter time: create the initial event to run until the time shift and a new copy to run thereafter.