539923 - Can't dismiss/snooze alarm when item contains multiple X-MOZ-LASTACK entries.

Status: NEW

(Calendar :: Alarms, defect)

Description

[Stefan Rijnhart]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102814 Ubuntu/8.04 (hardy) Firefox/3.0.15
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0

A recurring event on a caldav server has an exception. The exeption's X-MOZ-LASTACK triggers an alarm. When dismissed by the user, the main event's X-MOZ-LASTACK gets updated. The exception's X-MOZ-LASTACK triggers the alarm again, and so on.

The problem stops occuring when I manually remove all but the first of the "X-MOZ-LASTACK" lines from the entry in the caldav database.

We use the Davical server, version 0.9.7.6. Our database contains a number of items which display this behaviour.



Reproducible: Couldn't Reproduce

Steps to Reproduce:
It is unclear how these malformed(?) entries end up in the caldav database, but so far no other clients have been used but Lightning to interact with the server.
Actual Results:  
The wrong X-MOZ-LASTACK is updated.

Expected Results:  
I would expect Lightning to identify the correct X-MOZ-LASTACK and update this instead of the first X-MOZ-LASTACK.

Relevant log items:

[calAlarmService] considering alarm for item: agenda wekelijks naar SB sturen voor vrijdag overleg alarm time: 2010/01/06 08:25:00 UTC isDate=0 snooze time: null
[calAlarmService] now is 2010/01/15 11:24:15 UTC isDate=0
[calAlarmService] last ack was: 2009/11/05 10:28:11 UTC isDate=0
[calAlarmService] alarm is in the past and unack'd, firing now!

Actual caldav item:

CalDAV: send(http://testical/caldav.php/user1/home/: <calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <D:getetag/>
    <calendar-data/>
  </D:prop>
  <D:href>/caldav.php/user1/home/23a5b0bf-dea4-4f94-bb74-618fb191b7eb.ics</D:href>
</calendar-multiget>
CalDAV: send(http://testical/caldav.php/user1/home/): <?xml version="1.0" encoding="UTF-8"?>
<calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <D:getetag/>
    <calendar-data/>
  </D:prop>
  <D:href>/caldav.php/user1/home/23a5b0bf-dea4-4f94-bb74-618fb191b7eb.ics</D:href>
</calendar-multiget>
CalDAV: Status 207 fetching calendar-data for calendar Hatest
CalDAV: recv: <?xml version="1.0" encoding="utf-8" ?>
<multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
 <response>
  <href>/caldav.php/user1/home/23a5b0bf-dea4-4f94-bb74-618fb191b7eb.ics</href>
  <propstat>
   <prop>
    <getetag>"94c7038ae0c30b2b8f24bc65b224ab94"</getetag>
    <C:calendar-data>BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
X-LIC-LOCATION:Europe/Amsterdam
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20091104T090043Z
LAST-MODIFIED:20100115T114050Z
DTSTAMP:20100115T114050Z
UID:23a5b0bf-dea4-4f94-bb74-618fb191b7eb
SUMMARY:agenda wekelijks naar SB sturen voor vrijdag overleg
RRULE:FREQ=WEEKLY
EXDATE:20091111T100000Z
EXDATE:20091216T100000Z
EXDATE:20091223T100000Z
EXDATE:20091230T100000Z
X-MOZ-LASTACK:20100115T114050Z
DTSTART;TZID=Europe/Amsterdam:20091104T110000
DTEND;TZID=Europe/Amsterdam:20091104T120000
X-MOZ-GENERATION:87
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT5M
DESCRIPTION:Mozilla Alarm: agenda wekelijks naar SB sturen voor vrijdag ov
 erleg
END:VALARM
END:VEVENT
BEGIN:VEVENT
CREATED:20091210T110749Z
LAST-MODIFIED:20100115T110921Z
DTSTAMP:20100115T110921Z
UID:23a5b0bf-dea4-4f94-bb74-618fb191b7eb
SUMMARY:agenda wekelijks naar SB sturen voor vrijdag overleg
RECURRENCE-ID;TZID=Europe/Amsterdam:20100106T110000
X-MOZ-LASTACK:20091105T102811Z
DTSTART;TZID=Europe/Amsterdam:20100106T093000
DTEND;TZID=Europe/Amsterdam:20100106T103000
X-MOZ-GENERATION:17
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT5M
DESCRIPTION:Mozilla Alarm: agenda wekelijks naar SB sturen voor vrijdag ov
 erleg
END:VALARM
END:VEVENT
END:VCALENDAR
</C:calendar-data>
   </prop>
   <status>HTTP/1.1 200 OK</status>
  </propstat>
 </response>
</multistatus>

Comment 1

[Alex Sheppard]

I can confirm this problem is still present in Lightning 3.3.1. I can also reliably reproduce it!

1. Create a repeating event with reminders

2. In Lightning, snooze or dismiss a reminder

3. In another client (e.g. SOGo UI), alter your attendance for one instance of the repeating event

4. View source of the repeating event - notice that the exception VEVENT has inherited the X-MOZ-LASTACK property (and also the X-MOZ-SNOOZE-* property if you snoozed rather than dismissed).

5. When it is time for the reminder for the exception instance, having an X-MOZ-LASTACK in both the master VEVENT and the exception VEVENT confuses Lightning as already described in the bug report, and the reminder cannot be dismissed.


Whilst it can be argued that the other client is at fault for copying the X-MOZ-* properties to the exception VEVENT block (indeed I do argue that here <http://www.sogo.nu/bugs/view.php?id=2948>), I still think Lightning is at fault for responding to the exception VEVENT X-MOZ-LASTACK, but updating the X-MOZ-LASTACK in the master VEVENT. If a specific instance of a repeating event has it's own X-MOZ-LASTACK property, shouldn't that be the one that Lightning updates?

Comment 2

[Geert Lorang]

I can confirm this as well. Present in Lightning 3.3.3 with Zimbra 8.0.6 as back end.

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

Marking this as confirmed, but I'd appreciate a retest with the most recent version of Lightning and Thunderbird.

Comment 4

[Geert Lorang]

I can confirm still present like before on Win 10 + TB45.4.0 + Lightening 4.7.4