User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20061204 Firefox/184.108.40.206 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://firstname.lastname@example.org)
Update, news thread should start with nttp://email@example.com
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.
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.
Whiteboard: [qa discussion needed]
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:220.127.116.11pre) Gecko/20070327 Calendar/0.5pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
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).
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.
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.
Severity: critical → major
You need to log in before you can comment on or make changes to this bug.