371365 - Duplicates appear for alarms left in Calendar Alarm window

Status: VERIFIED FIXED

(Calendar :: Alarms, defect)

Description

[Bri]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3

I tend to leave some alarms in the Calendar Alarm window rather than snoozing them, so that I'll get to them when I have time.  After an hour or two, a duplicate of each alarm will appear in the Calendar Alarm window.

Reproducible: Always

Steps to Reproduce:
1. create some alarms
2. when they appear in the Calendar Alarm window, leave them there
3. after a while, a duplicate of each alarm appears

Actual Results:  
multiple copies of each alarm are in the Calendar Alarm window and must be dismissed separately.

Expected Results:  
the alarms would simply stay in the Calendar Alarm window until dismissed, but no duplicates would appear.

Comment 1

[Omar Bajraszewski]

WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.9a1) Gecko/20070213 Sunbird/0.3.1

Comment 2

[Bri]

Attachment: screen shot of Calendar Alarm window

See my comments below...

Comment 3

[Bri]

Hoping that it was because I was still using 0.3, I upgraded to the new version.  Same problem.  After several hours of the events staying up in a window, I got duplicates of all of them.  I even got three copies of one event (which happened to be a repeating event) one of was actually dated tomorrow (the next day the event was scheduled to occur).  I have attached a screen shot of the Calendar Alarm window.  The first three events appeared normally, and I left them undismissed and unsnoozed (I left them in the Calendar Alarm window).  After several hours, you can see that there were repeats of all the events.  Note also that this was all done on February 26th, but the last event is for the following day (February 27th).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20070213 Sunbird/0.3.1

-Bri

Comment 4

[Joey Minta]

So the problem here is that we re-set the alarm firing queue every 6 hours.  Because the items are still in the alarm window, they show up as un-acknowledged to our queries, which means we'll fire them again.  I'd suggest that the alarm window should be responsible for filtering these out, which should be pretty easy.

Comment 5

[Matthew (lilmatt) Willis]

This won't block 0.5, however we might take it if we get it fixed with enough qa time left.

Comment 8

[Daniel Boelzle [:dbo]]

(In reply to comment #4)
> So the problem here is that we re-set the alarm firing queue every 6 hours. 
> Because the items are still in the alarm window, they show up as
> un-acknowledged to our queries, which means we'll fire them again.  I'd suggest
> that the alarm window should be responsible for filtering these out, which
> should be pretty easy.

Yes, although this effectively means the code needs to observe all changes of all involved calendars and filter out the relevant ones for its window.
IMO it once again shows up that item value semantics is really a pain in the xyz. Reference semantics as proposed in <http://wiki.mozilla.org/Calendar:Architecture> would have performed better and would make the code more elegant since we could implement a change-listener mechanism per item. However, since we don't have time to rework the base code that way, I think it makes sense to add such functionality to calICalendarManager since the calendar manager already acts as a central service, e.g.

addObserverForItem(in calIItemBase item, in calIObserver observer);
removeObserverForItem(in calIItemBase item, in calIObserver observer);

It gets complicated if the item.calendar, item.id (, item.recurrenceId?) changes, which essentially modifies the item's origin, so the code needs to keep care to send out appropriate onDeleteItem notifications. Regarding occurrences, I think we should limit the use to parent items in the first place, keeping it simple.

Opinions?

Comment 9

[Stefan Sitter [:ssitter]]

Does this issue in this bug resp. Bug 385629 still exists using a recent 0.7pre nightly build after the checkin for Bug 389245?

Comment 10

[Eric Findlay]

This bug is still present in Sunbird 0.5:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4pre) Gecko/20070614 Sunbird/0.5

It appears to add another alarm every 30 minutes or so.

Comment 11

[Daniel Boelzle [:dbo]]

(In reply to comment #10)
Eric, Stefan talks about a recent *nightly* build. There hasn't been a fix for 0.5.

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070827 Calendar/0.7pre

Got an alert window and let it stay open for one day, got the alarms for two other events.

Actual results:
1. No duplicate alarms anymore.
2. Last alarm is shown again after closing and restarting calendar.

Haven't tried reproducing.

(And sorry that it isn't the nightly from today.)

Comment 13

[Stefan Sitter [:ssitter]]

(In reply to comment #12)
Thanks for retest. Resolving as fixed by the checkin for Bug 389245.

Comment 14

[Damian Szczepanik]

verified with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7pre) Gecko/20070908 Calendar/0.7pre

Comment 15

[Bri]

I can confirm that this bug is fixed in the nightly builds, but now I'm seeing a different problem that may or may not be related to the fix.

1. I have an alarm that is repeated weekly.
2. I receive the alarm normally.
3. I snooze the alarm each day for 7 days until the next alarm triggers.
4. There are now two similar alarms showing (but with different dates) as expected.
5. I dismiss the older of the two alarms.
6. The new alarm also disappears.

I would have expected the new alarm to stay if I only dismissed the older one.

Comment 16

[Stefan Sitter [:ssitter]]

(In reply to comment #15)
I just filed Bug 397030 for this issue.