367822 - Sunbird 0.3 may corrupt remote calendar if closed while popup alarm box is active

Status: RESOLVED DUPLICATE of bug 1305019

(Calendar :: Provider: ICS/WebDAV, defect)

Description

[eznie0ba]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3

I just upgraded from Sunbird 0.2 to Sunbird 0.3 after finding out that
changes for Daylight Saving Time would be added to Sunbird 0.3 and not
0.2.

I have been running 0.2 on two desktops (Window 2000 and Windows XP)
and one laptop (Windows 2000). I have one desktop running Apache
Tomcat 5.5 which provides WebDAV support and have my remote calendars
under it's control. All workstations are subscribed to these remote
calendars and have had no problems.

After installing Sunbird 0.3 on one desktop, I subscribed to the
remote calendars on the Tomcat server. No problems here, I could bring
up Sunbird 0.3 and see all my previous calendars. By default, I have
Sunbird set to remind me one day in advance of upcoming events, and to
show an alarm box and show missed alarms.

I entered a reminder for tomorrow (Monday Jan 22, 2006). As soon as I
saved the event, I heard a sound (default alarm sound), but proceeded
to close Sunbird, not really realizing that the alarm box had popped
up under my maximized Sunbird window. So, Sunbird is closed, and I see
the alarm box. I dismiss the alarm box and proceed to run Sunbird
again.

This time, Sunbird fails to load that one particular calendar with the
following error:

Error Number: ICS_NO_ERROR
Description: [Exception... "Component returned failure code:
0x804a0100 [calIICSService.parseICS]"  nsresult: "0x804a0100
(<unknown>)"  location: "JS frame ::
file:///C:/Program%20Files/Mozilla%20Sunbird/components/calICSCalendar.js
:: anonymous :: line 240"  data: no]

From that point on, I could not load that particular calendar file, as
this error occurs every time. I examined the actual .ICS file and it
appears to have been truncated, the last line of the .ICS file
consisted of:

   DESCRIPTI

This is reproducible every time, just set alarm for one day in
advance, enter an event for the next day, shutdown Sunbird, then
dismiss the alarm box. If you manage to see the alarm popup box and
switch to it and close it before closing Sunbird, all is well. The
corruption seems to occur if you enter an event, triggering an alarm
popup, closing Sunbird, then dismissing the event in the popup alarm.


Reproducible: Always

Steps to Reproduce:
1. Open Sunbird
2. Configure to alert one day in advance for events
3. Enter an event for tomorrow, have alarm window popup behind maximized Sunbird window
4. Close Sunbird
5. Immediately close alarm popup window
Actual Results:  
Calendar file is truncated.

Expected Results:  
Calendar file should be updated without being truncated

item posted to news.mozilla.org (nttp://[e-mail])

Comment 1

[eznie0ba]

Update, news thread should start with nttp://[e-mail]

Comment 2

[eznie0ba]

I had an existing calendar called CalendarHousehold.ics for general
household reminders, events, tasks.

Before running Sunbird:
	01/21/2007  02:31 PM            52,228 CalendarHousehold.ics

Added a new all day event for tomorrow entitled "Test", selected my
"House" calendar (I have 3 calendars on my local Tomcat server, and
the USHolidays hosted on a mozilla server) with a category of
Miscellaneous and click OK. 

I hear/see an alarm popup window appear behind maximized Sunbird and I
close Sunbird with alarm popup still active.

I then click the dismiss button on the popup alarm window and the
directory information shows:
	01/21/2007  05:16 PM            36,384 CalendarHousehold.ics

I repeated this test a few times and discovered that the actual final
file size varied after testing.

It may be timing related: If I enter my new event, then close Sunbird
by hitting the "X" button on the title bar, then immediately dismiss
the popup alarm, I see the files being truncated. 

If I wait a longer period of time after adding a new event/closing
sunbird .. then closing the alarm popup, the more likely it is that
the file will be fully written.

Again, these calendars files are under the control of a Tomcat 5.5
Server using WebDAV ... if that make any difference. 

Comment 3

[Bas van den Bosch]

This looks like the program/proces of writing the calendar is aborted as you closed. SB should wait shutting down the process until all write-operations are finished.  

Comment 4

[Sebastian Schwieger]

Confirmed. In my case, the file is eaten completely. I used Apache/WebDAV. The trick to reproduce is, that you have to be quick between closing Sunbird and Dismissing the event. This was tested with server and client being in the same subnet. I could imagine that this problem gets more apparent when file transfer is slow.
If I dismiss the event after waiting some seconds, the alarms pops up again after Sunbird restart.

Is more QA work needed or can qawanted keyword be cleared?

Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4pre) Gecko/20070327 Calendar/0.5pre

Comment 5

[Stefan Sitter [:ssitter]]

With the fix for Bug 355755 the alarms are not automatically dismissed anymore if Sunbird is closed and the alarm dialog is still open. This should prevent the problem in most of the cases. (Except when you manually provoke the problem).

Comment 6

[Bas van den Bosch]

I think snoozing the event will have the same effect (then data is written to the ics too iirc). It might even be reproduced by opening a new-event window, closing sunbird an then saving the event. The best fix would be to start closing the sunbird process only after all child-windows have been closed and directly after this wait till all write-operations are finished. The first part may already be true btw. A simpeler, less elegant, solution would be to only have the second part, wait shutting down the sunbird-process until all write-operations have finished.

Comment 7

[cmtalbert]

The problem here is that the write seems to occur after the shutdown process has already begun.  The update should simply fail, and not attempt to actually modify the ICS.  Due to the fix on 355755, this only occurs when you force sunbird into this situation, and does not occur auotmatically, so we are decreasing status to "Major", and removing the QAWanted flag.