554722 - event/task creation fails if alarm unit preference contains an unexpected value [Exception "Cannot modify properties of a WrappedNative" in calAlarmUtils.jsm]

Status: RESOLVED FIXED

(Calendar :: Dialogs, defect)

Description

[Malte Boisly]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Gentoo Firefox/3.5.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.3

It is not possible to open the dialogs for creating a new date or task by menu or by context menu. An error message occurs in the error console.

Reproducible: Always

Steps to Reproduce:
1. Check about:config for entry "calendar.alarms.[event|todo]alarmunit"
2. Insert property, if missing. Remove value, if set.
3. Switch to calendar view.
4. open the context menu for a day. Choose "New date" or "New task".

Actual Results:  
An uncaught exception is thrown and written to error console.
Fehler: uncaught exception: [Exception... "Cannot modify properties of a WrappedNative" nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)" location: "JS frame :: file:/// ... /extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calAlarmUtils.jsm :: cal_alarm_setDefaultValues :: line 54" data: no]


Expected Results:  
The dialogs should appear.

The error is located in file "calAlarmUtils.jsm" line 53.
The default value for units is set to "minute" if no value is set.
While debugging the object "alarmOffset" shows only a member "minutes" - with an "s".

Workaround:
Define the properties "calendar.alarms.[event|todo]alarmunit" to the value "minutes" manually and the dialogs will appear again.

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

So these preferences were missing for you? This could be bug 532874.

If you start a new profile and don't use about:config to change the values, but rather the Lightning Options dialog, do you get the same error?

Comment 2

[Stefan Sitter [:ssitter]]

Attachment: [checked in] use valid default alarm unit if pref is missing

Using a valid default value in case the pref is missing is always good. But it doesn't prevent the failure if the pref exists but with an invalid value.

Comment 3

[Malte Boisly]

(In reply to comment #1)
> So these preferences were missing for you? This could be bug 532874.
> 
> If you start a new profile and don't use about:config to change the values, but
> rather the Lightning Options dialog, do you get the same error?

The Property was not missing! Only the value to it.
So Lightning took the default value. To make anyone able to reproduce this issue I made step 2 failsave.

I now created a new profile for test purpose and downloaded and installed the Lightning add-on (1.0b1). No manual changes were made at the config page (about:config). I made no changes within config dialogs. I then switched to the calendar view and made a double click (left) on a day field.
=> Dialog opens!
Afterwards I opened the config page and the properties exist with values! The value is set to "minutes".


So it seems to me this issue occurs also because a former Lightning version did not write the value to the properties. But, don't ask me wich version I ran before - I updated TB2.x to TB3 and Lightning was updated during TB3 startup.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 434718 [details] [diff] [review]
[checked in] use valid default alarm unit if pref is missing

r=philipp

Does this also fix bug 532874?

Comment 5

[Stefan Sitter [:ssitter]]

No. The patch doesn't fix the issue reported here either. If the preference exists but contains an unexpected value the code will still fail.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Could you attach a patch that also checks if this is a valid property (either by creating a map with minutes,hours,days, or at least by checking obj.hasOwnProperty() ?

Comment 7

[Stefan Sitter [:ssitter]]

Comment on attachment 434718 [details] [diff] [review]
[checked in] use valid default alarm unit if pref is missing

checked in to <https://hg.mozilla.org/comm-central/rev/31fa8862028d>

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The rest of this bug will be fixed in bug 532874.