Closed Bug 349715 Opened 14 years ago Closed 13 years ago

Error: "alarmTime has no properties" on tasks created by KDE Kontact

Categories

(Calendar :: Alarms, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: andrewz, Assigned: ssitter)

References

Details

(Whiteboard: [fixed0.3.1])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

A certain iCal item causes a JavaScript error.

Reproducible: Always

Steps to Reproduce:
1. Delete the Sunbird data directory.
2. Either "File->Import" or "File->Subscribe to remote calendar" to the attached .ics.

Actual Results:  
Error: uncaught exception: [Exception... "'[JavaScript Error: "alarmTime has no properties" {file: "file:///C:/Documents%20and%20Settings/andrewz/Desktop/sunbird-0.3a2+.en-US.win32/sunbird/js/calAlarmService.js" line: 348}]' when calling method: [calIOperationListener::onGetResult]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///C:/Documents%20and%20Settings/andrewz/Desktop/sunbird-0.3a2+.en-US.win32/sunbird/components/calStorageCalendar.js :: queueItems :: line 580"  data: yes]

Expected Results:  
No error messages.

Same error message as issue 336766 (which is fixed), but I verified that the sample file in that issue no longer causes an error.
Sigh... someone really needs to take the VALARM part of rfc2445 out back and shoot it.

From 4.8.6.3 
  "The default duration is relative to the start of an event or to-do
   that the alarm is associated with. The duration can be explicitly set
   to trigger from either the end or the start of the associated event
   or to-do with the "RELATED" parameter."

The alarm attached here applies to a todo with only a DUE property.  According to my reading of the above, this means the TRIGGER is required to have RELATED:END.  Otherwise, we're to assume that the alarm corresponds to the (non-existent in this case) DTSTART property of the task.

Note that it's not too hard to have our code also handle this interpretation, but I'm not sure I want to go down the road of encouraging deviations from the standard.  In that case, this is a bug in Kontact.


Attached patch patch (obsolete) — Splinter Review
For reference, this is that patch that would probably fix this bug.  Untested, but straightforward enough.
For cross reference, the new KDE bug is http://bugs.kde.org/show_bug.cgi?id=132818
The patch from comment #4 does not seem to help in this case, but applying a very similar fix near line 348 makes the error message go away.

if (aItem.alarmRelated == Components.interfaces.calIItemBase.ALARM_RELATED_START) {
-            alarmTime = aItem.startDate || aItem.entryDate;
+            alarmTime = aItem.startDate || aItem.entryDate || aItem.dueDate;
        } else {
            alarmTime = aItem.endDate || aItem.dueDate;
        }
(In reply to comment #5)
> The patch from comment #4 does not seem to help in this case, but applying a
> very similar fix near line 348 makes the error message go away.
Oh, oops.  You need both, otherwise snoozing that alarm wouldn't work. :-)
Updating summary as this is caused by a non-standard *.ics produced by KDE Kontact.
Open Question: Should Calendar follow the standard or or make Calendar less strict and accept that *.ics?
Summary: JavaScript Error: "alarmTime has no properties" → Error: "alarmTime has no properties" on tasks created by KDE Kontact
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
This hopefully helps on Bug 351977, Bug 356000 and Bug 356004 too.
Assignee: nobody → ssitter
Attachment #234941 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #241841 - Flags: second-review?(dmose)
Attachment #241841 - Flags: first-review?(lilmatt)
*** Bug 351977 has been marked as a duplicate of this bug. ***
*** Bug 356004 has been marked as a duplicate of this bug. ***
Comment on attachment 241841 [details] [diff] [review]
make alarm handling less strict, fallback to date / due date

r=lilmatt
Attachment #241841 - Flags: first-review?(lilmatt) → first-review+
Blocks: 356000
Comment on attachment 241841 [details] [diff] [review]
make alarm handling less strict, fallback to date / due date

Moving r2 to ctalbert per dmose
Attachment #241841 - Flags: second-review?(dmose) → second-review?(cmtalbert)
Comment on attachment 241841 [details] [diff] [review]
make alarm handling less strict, fallback to date / due date

Looks good. As a side note, we should figure out how to best drive clarification on these pieces of RFC 2445.
Attachment #241841 - Flags: second-review?(cmtalbert) → second-review+
Patch checked in on MOZILLA_1_8_BRANCH and trunk.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #13)
> As a side note, we should figure out how to best drive
> clarification on these pieces of RFC 2445.

calsify

The attached ics file does not result in error message any more. It fires an alarm. (I changed the due date to 1st of May 2006 in order to get the alarm) 
-> Verified fixed
Status: RESOLVED → VERIFIED
Flags: blocking-calendar0.3.1?
Taking for 0.3.1 because it also gets trigged by old Sunbird/Lightning alarms, not just KDE alarms (see bug 356004).
Flags: blocking-calendar0.3.1? → blocking-calendar0.3.1+
Patch checked in for 0.3.1

LIGHTNING_0_3_BRANCH:
Checking in calAlarmService.js;
/cvsroot/mozilla/calendar/base/src/calAlarmService.js,v  <--  calAlarmService.js
new revision: 1.8.2.13.2.1; previous revision: 1.8.2.13

SUNBIRD_0_3_BRANCH:
Checking in calAlarmService.js;
/cvsroot/mozilla/calendar/base/src/calAlarmService.js,v  <--  calAlarmService.js
new revision: 1.22.2.1; previous revision: 1.22

Marking [fixed0.3.1]
Whiteboard: [fixed0.3.1]
You need to log in before you can comment on or make changes to this bug.