336766 - JavaScript Error: "alarmTime has no properties"

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[andrewz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Dialog comes up with this error information:

Error number: 0x80570021

[Exception... "'[JavaScript Error: "alarmTime has no properties" {file: "file:///C:/Documents%20and%20Settings/andrewz/Application%20Data/Thunderbird/Profiles/hpjuuq72.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calAlarmService.js" line: 333}]' when calling method: [calIObserver::onAddItem]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///C:/Documents%20and%20Settings/andrewz/Application%20Data/Thunderbird/Profiles/hpjuuq72.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calICSCalendar.js :: anonymous :: line 801"  data: yes]

Reproducible: Always

Steps to Reproduce:
1. Make my WebDAV calendar not read-only

Actual Results:  
The above error is displayed in a dialog.  Then, that calendar goes into read-only mode.

Expected Results:  
No error

I tried with different builds:
ftp://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.1/lightning-0.1-windows.xpi
ftp://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-mozilla1.8/windows-xpi/lightning.xpi

Comment 1

[Joey Minta]

Can you try to track down which item is causing this and attach the ics for that event to this bug?  It seems like a rather pathological item that is missing either a start or end time, but tries to have an alarm corresponding to that time.

Comment 2

[andrewz]

Attachment: bad to do

created using Mozilla Lightning and KDE Korganizer

Comment 3

[Stefan Sitter [:ssitter]]

Same tasks related problem and error message have been reported in german forum [http://www.sunbird-kalender.de/forum/viewtopic.php?p=3240#3240] today with Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9a1) Gecko/20060502 Mozilla Sunbird/0.3a2RC1. -> Marking confirmed

Comment 4

[Stefan Sitter [:ssitter]]

This error can happen during import of tasks created in Sunbird 0.2:

1. Start Sunbird 0.2 (20050203)
2. Create an new task, set a due date (but no start date)
3. Add alarm, e.g. 15 minutes after task is due
4. Start Sunbird 0.3a2 (20060505)
5. Select File->Import and select the ics file from Sunbird 0.2 profile

I added some dumps and get the following console output during import:

  setItemBaseFromICS(): trigger value=-PT15M
  setItemBaseFromICS(): trigger parameter 'RELATED'=END
  setItemBaseFromICS(): set this.alarmRelated to this.ALARM_RELATED_END
  setItemBaseFromICS(): (this.alarmRelated = undefined)
  setItemBaseFromICS(): (this.ALARM_RELATED_START = undefined)
  setItemBaseFromICS(): (this.ALARM_RELATED_END = undefined)
  addAlarm(): aItem.alarmRelated == aItem.ALARM_RELATED_START -> use start date
  addAlarm(): aItem.startDate=undefined
  addAlarm(): aItem.entryDate=null
  addAlarm(): alarmTime=null
  addAlarm(): (aItem.alarmRelated = 0)
  addAlarm(): (aItem.ALARM_RELATED_START = 0)
  addAlarm(): (aItem.ALARM_RELATED_END = 1)

Comment 5

[Stefan Sitter [:ssitter]]

Attachment: patch attempt

This patch fixes the problem with ALARM_RELATED_START and ALARM_RELATED_END being undefined before using them in setItemBaseFromICS(). This allows me to import this kind of tasks from Sunbird 0.2 and the alarm is set up correctly.

But that brings up some questions to me:

Both attributes are declared in calIItemBase.idl as 
  const unsigned long ALARM_RELATED_START = 0;
  const unsigned long ALARM_RELATED_END = 1;

Why are they undefined in setItemBaseFromICS()? When are they initialized?

Why can I change both values inside setItemBaseFromICS() although they are declared as const? For example I can set this.ALARM_RELATED_END to 2. But later in addAlarm() it will be 1 again. Who or what resets this value in between?

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 221146 [details] [diff] [review]
patch attempt

This is not good.
The use of this.ALARM_RELATED_START is what causes the problem. That should be Components.interfaces.calIItemBase.ALARM_RELATED_START (or define a const for ci.calIItemBase)

Most other usages found by http://lxr.mozilla.org/seamonkey/search?string=ALARM_RELATED_START (and ...-END) also don't look good. They should use the same construct.

(The problem you saw may be caused by xpconnect. this.ALARM_RELATED_START should work once xpconnect sees that the object also implements calIItemBase. Then it can get the constants from there.)

Comment 7

[Stefan Sitter [:ssitter]]

Attachment: use Components.interfaces.calIItemBase

Thanks for the hint Michiel.

Comment 8

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 221158 [details] [diff] [review]
use Components.interfaces.calIItemBase

r=mvl

Comment 9

[Matthew (lilmatt) Willis]

Patch checked in on trunk and MOZILLA_1_8_BRANCH per ssitter.

Comment 10

[Reed Loden [:reed]]

The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!