231765 - Calendar cannot handle more than four exceptions for a single event

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[David J. Lynch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208

When there are more than four exceptions, the fifth and any subsequent
exceptions are displayed in the UI and written to the ics file as 1969-12-31.
Hand-editing the ics file to have more than four exceptions produces the same
result.

Reproducible: Always

Steps to Reproduce:
1. Create a recurring event
2. Add more than four exceptions
3.

Actual Results:  
UI and ICS file have 1969-12-31 as the dates for the fifth and all subsequent
exceptions.

Expected Results:  
Calendar should be able to handle more exceptions.

Using 2004-01-09 XPI release.

Comment 1

[Jussi Kukkonen]

*** Bug 234132 has been marked as a duplicate of this bug. ***

Comment 2

[Jussi Kukkonen]

Confirming. 

The amount of exceptions is not the only thing needed to trigger this. My test
case with an event recurring daily for four months:
- added four exceptions
- added another four
- added another four
- added another four. This one failed, the four exceptions did not show up, but
one on 1.1.1970 did.

Comment 3

[gekacheka]

This appears to be an XUL element or listbox/listitem bug.
The value (and label) of the list item is not accessible through the .value (and
.label) property if the listitem is never shown in the visible rows.

A user workaround before patch is applied is to scroll the execeptions so all
the added exceptions are displayed before closing the dialog.

A code workaround is to either (a) access the value through
listitem.getAttribute("value") instead of the property listitem.value, or (b)
use ensureElementIsVisible to scroll the listbox to make the newly added item
visible at least once before accessing listitem.value.

Evidence:

In eventDialog.xul, the exception-dates-listbox has attribute rows="4", so it
produces at most 4 visible rows and scrolls the rest.

I tried adding the following code around the call to listbox.appendItem in 
addException (at eventDialog.js:1204):
----------
   // debug
   dump("\n dateToAdd: "+dateToAdd+", DateLabel: "+DateLabel+",
time="+dateToAdd.getTime());
   // end debug

   //add a row to the listbox
   document.getElementById( "exception-dates-listbox" ).appendItem( DateLabel,
dateToAdd.getTime() );

   // debug
   var listbox = document.getElementById( "exception-dates-listbox" );
   var lastItem = listbox.getItemAtIndex(listbox.childNodes.length - 1);
   dump("\n Appended lastItem(label="+lastItem.label+", value="+lastItem.value+")");
   var attrs = lastItem.attributes;
   dump("\n attribute count = "+attrs.length);
   for (var a = 0; a < attrs.length; a++) {
     dump("\n attr["+a+"]: "+attrs[a].nodeName+" = "+attrs[a].nodeValue);
   }
   // end debug
----------
It produced a trace like the following for the first four additions:
----------
 dateToAdd: Fri Jul 16 2004 20:00:00 GMT-0400 (Eastern Daylight Time),
DateLabel: 2004-07-16, time=1090022400000
 Appended lastItem(label=2004-07-16, value=1090022400000)
 attribute count = 2
 attr[0]: label = 2004-07-16
 attr[1]: value = 1090022400000
---------
After the first four (visible rows filled), when a new item is appended, it is
not visible, and the result is a trace like the following:
----------
 dateToAdd: Tue Jul 27 2004 20:00:00 GMT-0400 (Eastern Daylight Time),
DateLabel: 2004-07-27, time=1090972800000
 Appended lastItem(label=undefined, value=undefined)
 attribute count = 2
 attr[0]: label = 2004-07-27
 attr[1]: value = 1090972800000
----------
As you can see, accessing the .label and .value properties produced the
undefined value, but the attributes do exist.

If the added dates are not scrolled into view before closing the dialog, and
then edit the event again, the added dates that were not viewed are not recorded.

If the added dates are scrolled into view before closing the dialog, when the
event is edited again, the added dates are there.

Comment 4

[gekacheka]

Attachment: eventDialog.js, todoDialog.js patch addException to ensure item is visible so item.value will work

Ensuring the appended item becomes visible is simpler than looking for all the
places where item.value is accessed and changing them to use getAttribute.  It
is also better for the user to see that the new value was indeed added to the
list.

Comment 5

[Mostafa Hosseini]

Checked in. Thanks

Comment 6

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

ensureElementIsVisible now is used for other purposes then only making it
visible. Could you add a comment on that?

Comment 7

[gekacheka]

Attachment: eventDialog.js, toDoDialog.js patch: add comment ( checked in )

Adds comment as requested to both files
  //ensure user can see that add occurred (also, avoid bug 231765, bug 250123)

Comment 8

[Reed Loden [:reed]]

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