523987 - Dismissing alarms doesn't work with Provider for Google Calendar

Status: RESOLVED FIXED

(Calendar :: Provider: GData, defect)

Description

[swordphsh]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009090217 Ubuntu/9.04 (jaunty) Firefox/3.0.14
Build Identifier: Lightning version 1.0pre Build ID: 20091022031054

I'm using the gCal extension, and every time my google calendar reloads, automatically or manually, all my set notification alerts from the past month of so "go off," or are displayed in a very large list on my screen. Every time I click "dismiss all" yet they come back when the calendar is refreshed. Bug is not present with locally saved calendars.

Reproducible: Always

Steps to Reproduce:
1. Google calendar is reloaded within lightning and past events have "notification" alarms.
2. Click dismiss all or dismiss each individually
3. Reload google calendar
4. Same event notifications appear again.
Actual Results:  
In my case, 23 out-dated notification alarms appear on my screen.

Expected Results:  
Past events should not appear once dismissed.

I keep everything (thunderbird 3 beta, lightning, gcal provider) up to date daily. The problem began happening today with the latest updates.

Comment 1

[Stefan Sitter [:ssitter]]

Google Calendar added support to snooze alarms on 2009-10-21 according to <http://googleappsupdates.blogspot.com/2009/10/enhancements-to-google-calendar.html>

Maybe they broke alarm handling for external applications like Lightning with this change.

Comment 2

[swordphsh]

That's a possibility, but do the google notifications relay through lightning, or is that lightning's notification system triggered by seeing the alert set within the calendar?

I'd just like to note that the problem did start on the morning of 10/22 after an update of Thunderbird, Lightning, and gCal Provider.

Comment 3

[swordphsh]

It's probably helpful to note this: Upon enabling the experimental "cache" mode under the calendar properties (within lightning), the problem disappears entirely. 

It seems to me that without the cache, when the google calendar is refreshed, it's "forgetting" that it had previously existed and, I guess, overwriting the existing file, causing it to display the alerts that it believes were just created and never before displayed.

(I am in no way a programmer, so I have no idea what is actually happening. That's just my speculation based on my observations.)

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

With the cache disabled, please enable calendar debugging (see https://wiki.mozilla.org/Calendar:GDATA_Provider) and check what happens when you dismiss a single entry.

Comment 5

[swordphsh]

Upon dismissing a single entry, I receive the following in the error console under "messages" (in First > Last Sort Order):

Modifying item Wash
Not requesting item modification for jmim93vasfg3u1ai98sp86u984(Wash), relevant fields match
[calAlarmService] considering alarm for item: Wash alarm time: 2009/10/21 19:45:00 UTC isDate=0 snooze time: null
[calAlarmService] now is 2009/10/31 18:26:49 UTC isDate=0
[calAlarmService] last ack was: 2009/10/31 18:26:49 UTC isDate=0
[calAlarmService] Wash - alarm previously ackd.

The event was scheduled for 10/21 at 4PM.

Comment 6

[Mircea Trandafir]

I can confirm this bug. I would bump it to "importance: critical"  because it is very easy to miss new and relevant alerts when they are included in a long list of "missed alerts" that gets displayed every time the remote calendars are reloaded. It defeats the whole purpose of having alarms! 

Also, the caching solution doesn't work when having more than one remote calendar (bug 479867), so at this point I'm stuck with having to dismiss alarms every x minutes and having to check them ever time for new event alarms.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Confirmed, this needs to be fixed before the beta release. Working on a patch.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v1

This patch takes care. Seems this somehow got lost along the way.

Comment 9

[Mircea Trandafir]

Thanks Philipp, the patch seems to be working. I did get an "error - modification failed" when I dismissed the alarms, but they didn't pop up again when I reloaded the calendar.

Comment 10

[Martin Schröder [:mschroeder]]

Comment on attachment 411999 [details] [diff] [review]
Fix - v1

r=mschroeder, but maybe better place it before the comment referencing startDate/endDate.

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Yeah, you're right. Changed that.

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/34fad47b9de0>
and comm-1.9.1 <http://hg.mozilla.org/releases/comm-1.9.1/rev/b1cb301aa974>

-> FIXED