absolute alarm with fixed date/time is lost after application restart, no further changes to calendar possible

VERIFIED FIXED in 1.0b1

Status

defect
--
major
VERIFIED FIXED
11 years ago
8 years ago

People

(Reporter: ssitter, Assigned: Fallen)

Tracking

({dataloss})

Bug Flags:
blocking-calendar1.0 +
in-testsuite +

Details

Attachments

(1 attachment)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090327 Calendar/1.0pre

Steps to Reproduce:
1. Start Sunbird with clean profile
2. Start creating a new event, e.g. 01-Apr-2009 10:00-12:00.
3. Add a custom with fixed date/time, e.g. 31-Mar-2009 16:00
4. Save the event
5. Restart application
6. Open the event, check alarm settings, change title, save.

Actual Results:
A custom alarm '' (no displayed text) is shown. 
Saving the title changes fails, event dialog stays open. Console shows: 
[[[
Error: uncaught exception: [Exception... "'Illegal value' when calling method: [calIItemBase::addAlarm]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://calendar/content/calendar-dialog-utils.js :: saveReminder :: line 560"  data: no]
]]]

Copy to clipboard or moving the event in the view fails with:
[[[
An error occurred executing the cmd_copy command
[Exception... "'Component not initialized' when calling method: [calIAlarm::icalComponent]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: file:///E:/sunbird/calendar-js/calItemBase.js :: cIB_fillIcalComponentFromBase :: line 905"  data: no]
]]]

Trying to add another event fails with:
[[[
Warning: There has been an error reading data for calendar: ICS. It has been placed in read-only mode, since changes to this calendar will likely result in data-loss.  You may change this setting by choosing 'Edit Calendar'. Error code: 0xc1f30001. Description: The calendar could not be saved; there was a failure: 0xc1f30001

Error: An error occurred when writing to the calendar ICS! Error code: MODIFICATION_FAILED. Description: 
Source File: file:///E:/sunbird/calendar-js/calCalendarManager.js
Line: 963
]]]

Expected Results:
A custom alarm with fixed date/time as created is shown. Event can be changed and saved. Other events can be added.
Flags: blocking-calendar1.0?
Is this a libical issue? Do they support absolute alarms? I created the following unittest example for test_alarm.js:

  function test_parse() {
      dump("Testing alarm parsing...");

      // alarm 15 minutes before the event/task starts
      let str1 = "BEGIN:VALARM\n" +
                 "ACTION:DISPLAY\n" +
                 "TRIGGER;VALUE=DURATION:-PT15M\n" +
                 "DESCRIPTION:Default Mozilla Description\n" +
                 "END:VALARM";
      let alarm1 = cal.createAlarm();
      alarm1.icalString = str1;
      do_check_eq(alarm1.related, Ci.calIAlarm.ALARM_RELATED_START);

      // absolute alarm at 2009-04-30 08:00 UTC
      let str2 = "BEGIN:VALARM\n" +
                "ACTION:DISPLAY\n" +
                "TRIGGER;VALUE=DATE-TIME:20090430T080000Z\n" +
                "DESCRIPTION:Default Mozilla Description\n" +
                "END:VALARM";
      let alarm2 = cal.createAlarm();
      alarm2.icalString = str2;
      do_check_eq(alarm2.related, Ci.calIAlarm.ALARM_RELATED_ABSOLUTE);

      dump(" Done\n");
  }

The first check passes, the second one fail.
Keywords: dataloss
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Something is really strange. Although my xpcshell unittest framework seems to be borked, I executed these manually in xpcshell and everything seemed fine.
I'll retest with tomorrows nightly build. Maybe the checkins for bug 353492 magically fixed it.
Fails in Sunbird 1.0pre (BuildID: 20090402125816)
Works in Sunbird 1.0pre (BuildID: 20090402141537)

--> FIXED by checkin from Bug 367469 Comment #12 or Bug 353492 Comment #93.
Assignee: nobody → philipp
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
This test check that the RELATED property is correctly set after parsing the given VALARM component. I'm not sure about the following example (not contained in xpcshell test):

RFC2445bis-09 Chapter 4. iCalendar Object Examples contains the following example for an alarm with the trigger set to an absolute date/time <http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-4>:

        BEGIN:VALARM
        ACTION:AUDIO
        TRIGGER:19980403T120000Z
        ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio-
         files/ssbanner.aud
        REPEAT:4
        DURATION:PT1H
        END:VALARM

But RFC2445bis-09 Chapter 3.8.6.3. Trigger states that "VALUE=DATE-TIME" is required for absolute triggers <http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-3.8.6.3>: 

        trigger    = "TRIGGER" (trigrel / trigabs) CRLF

        trigabs    = *(

                   ; the following is REQUIRED,
                   ; but MUST NOT occur more than once

                     (";" "VALUE" "=" "DATE-TIME") /

                   ; the following is OPTIONAL,
                   ; and MAY occur more than once

                   (";" other-param)

                     ) ":" date-time

Looks like an error in specification or example?
Attachment #370883 - Flags: review?(philipp)
I'd say bug in the spec.
Flags: in-testsuite?
Comment on attachment 370883 [details] [diff] [review]
xpcshell testcase

r=philipp.

I think that DATE reminders don't make sense, the default trigger value is a duration and the bug is in the example rather than in the specification of the trigger property.
Attachment #370883 - Flags: review?(philipp) → review+
Comment on attachment 370883 [details] [diff] [review]
xpcshell testcase

Pushed to comm-central: <https://hg.mozilla.org/comm-central/rev/d95bc75b6a72>
Flags: in-testsuite? → in-testsuite+
OS: Windows XP → All
Hardware: x86 → All
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090611 Calendar/1.0pre (BuildID: 20090611031611)
Status: RESOLVED → VERIFIED
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.