270645 - RecurInterval is set to 1 even though no recurrance is set for the event

Status: RESOLVED WORKSFORME

(Calendar :: Internal Components, defect)

Description

[ago]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

RecurInterval is set to 1 when event is edited+saved+reloaded even though no
recurrance is set for the event

Reproducible: Always
Steps to Reproduce:
1. Create an event
2. Edit the title
3. save it using gICalLib.modifyEvent()
4. reload using gICalLib.removeCalendar() + gICalLib.addCalendar()
5. check Event.recurInterval

Comment 1

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

I'd say that all the recur* properties are invalid and meaningless unless recur
is true. If there is no recurrence, the settings for the recurrence make no sense
Other then that, a default value of 1 makes more sense the 0. 'repeat every 0
days' ?

Comment 2

[ago]

> If there is no recurrence, the settings for the recurrence make no sense

If they are not used they should not be touched... 

Comment 3

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

When i said 'invalid' i was a bit wrong.
It should be documented that when occur is false, those values can be defaults,
and don't contain any actualdata about the event, and can be ignored.
Because it are defaults, they can change. but why care, because they don't
contain any imporant data?

Comment 4

[ago]

If properties are altered that should not be altered (because irrelevant), that
is an indication that something is wrong... I did not dive into the code to see
what is actually going on, but I think it would be wise to check.

Even if it just a useless flag (in the sense that it is reset when actually it
is not needed), it might be a problem if you had to do a comparison say to check
if the event you just edited was actually been saved to a file. This comparison
will always evaluate to false, because the flag changes, unless you use a
workaround. At least this bug will alert developers working on a compare method... 

PS It is related to the X-MOZILLA-RECUR-INTERVAL setting, you'll see this if you
use getIcalString()... 

Comment 5

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

(In reply to comment #4)
> If properties are altered that should not be altered (because irrelevant), that
> is an indication that something is wrong... 

It isn't irrelevant. It is a default value. However, it can be ignored if you
want to find out if two events are different, because it are defaults, and no
actual data.

Comment 6

[ago]

> It is a default value. 

???? And how comes that sometime the "default" value is 0 and sometime it is 1? 

Comment 7

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

Because i worded it wrong. It isn't a default in general, but a default for the
next time the event is opened. And it remembers the last value. If the event is
never opened, it is 0. Once opened, it stores the last value, which is set to 1
if nothing is present yet.

Comment 8

[Matthew (lilmatt) Willis]

Moving this to libical since that (apparently) is the cause of the woe.

See 
http://lxr.mozilla.org/mozilla/source/calendar/resources/content/eventDialog.js#605 

If with the libical upgrade this is no longer necessary, then great. Let's
remove the offending code.
 
Otherwise, I think it's innocuous and nominate for WONTFIX.

Comment 9

[Joey Minta]

Resolving WORKSFORME.  From everything I can tell, the new backend components don't set any recurInterval for one-time events.

Comment 10

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Internal Components. Be afraid for your sanity!