Closed Bug 315511 Opened 19 years ago Closed 18 years ago

New remote calendar is readonly first and a error message appears


(Calendar :: General, defect)

Not set


(Not tracked)



(Reporter: thorsten, Assigned: mvl)




(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051031 Firefox/1.5 (pigfoot)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a1) Gecko/20051104 Mozilla Sunbird/0.3a1

If you create a remote calendar, you will get a error message box (see in the Actual Results field). It looks like sunbird tries to access the calendar file before it is created. After you have closed the message box, you have to edit the calendar and uncheck the "readonly" checkbox. Then everything is ok.

Reproducible: Always

Steps to Reproduce:
1. Create a new remote calendar
2. You get the error message box then
3. Close it and go to "Edit calendar" and uncheck the "readonly" checkbox.
4. Then you can work on the remote calendar file.

Actual Results:  
There has been an error reading data for calendar: test23. It has been placed in read-only mode, since changes to this calendar will likely result in data-loss.  You may change this setting by choosing 'Edit Calendar'.
Errornumber : 0x804a0107
Description : [Exception... "Component returned failure code: 0x804a0107 [calIICSService.parseICS]"  nsresult: "0x804a0107 (<unknown>)"  location: "JS frame :: file:///D:/sunbird-0.3a1-dt/components/calICSCalendar.js :: anonymous :: line 396"  data: no]

Expected Results:  
The new remote calendar file should be created without this error message and the new remote calendar should be accessable without this workaround (unchecking the "readonly" checkbox).
What CalDAV server are you using?
I used a WebDAV-folder not a CalDAV-server.
I have got reading and writing rights on this WebDAV-folder.
Assignee: dmose → mostafah
Component: CalDAV provider → General
QA Contact: caldav-provider → general
I'm getting the same error myself, but when I uncheck the read-only box I get a 404 when I try to edit the calendar.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051104 Mozilla Sunbird/0.3a1

Trying to use webDAV on dreamhost
> Errornumber : 0x804a0107

The only place this seems to be able to come from, is
And i do see it coming from there, on startup.

#0  icalerror_set_errno (x=ICAL_FILE_ERROR)
    at /home/michiel/mozhack/tree1/mozilla/calendar/libical/src/libical/icalerror.c:99
#1  0x058a72aa in icaltimezone_parse_zone_tab ()
    at /home/michiel/mozhack/tree1/mozilla/calendar/libical/src/libical/icaltimezone.c:1441
#2  0x058a716b in icaltimezone_init_builtin_timezones ()
    at /home/michiel/mozhack/tree1/mozilla/calendar/libical/src/libical/icaltimezone.c:1398
#3  0x058a713c in icaltimezone_get_utc_timezone ()
    at /home/michiel/mozhack/tree1/mozilla/calendar/libical/src/libical/icaltimezone.c:1382
#4  0x0587d6f2 in calDateTime::GetIcalTZ ()
   from /home/michiel/mozhack/tree1/obj-sb/dist/bin/components/

I don't see an easy way around this.
mvl: Any chance you could get that trace again, but using "where full" on a debug build, and pasting more frames of the stack? 
I don't have a debug build handy, but I think the problem is pretty clear:
we use icaltimezone_get_utc_timezone(), which wants to read the entire timezone table by reading But we don't ship, so a file-not-found error is thrown.
A possible solution might be to comment out but i'm not sure what the results would be. How do we try to handle timezones, and how does libical handle them?
The first time I start any new build of Sunbird, I get a crash, along with this error, which seems to be the same issue:

*** Calendar schema version is: 4
observer added
observer removed
Parsing the file failed:[Exception... "Component returned failure code: 0x804a0100 [calIICSService.parseICS]"  nsresult: "0x804a0100 (<unknown>)"  location: "JS frame :: file:///usr/local/src/mozilla/sunbird/sunbird-200512280847/components/calICSCalendar.js :: anonymous :: line 396"  data: no]
/usr/local/src/mozilla/sunbird/sunbird-200512280847/ line 131: 11317 Segmentation fault      "$prog" ${1+"$@"}

Simply starting Sunbird again cures it, and from then on that particular build will be fine. Take a fresh build, and the first run of it will produce the same issue.

This on Linux/x86, my own builds from CVS. Been happening for a little while.

I have one local calendar, and subscribe to a few remote holiday calendars (from e.g. Apple). They're not marked read-only, although I have no intention of trying to change them, of course, so perhaps they should be.

Is this the same issue? 
(In reply to comment #8)
> The first time I start any new build of Sunbird, I get a crash, along with this
> error, which seems to be the same issue:
> ...snip...
> Is this the same issue? 
No, this is about subscribing to a calendar once Sunbird has started up.  Specifically, this is about "Component returned failure code: 0x804a0107" (ICS_FILE).  Your error is 0x804a0100 (ICS_NO_ERROR).  I'm 95% sure this is thrown in normal cases by the presence of an empty ICS calendar in your subscribed list of calendars.

The crash is almost certainly caused by something else, perhaps using the same profile with different versions of Sunbird.  If you're making your own builds of Sunbird, try compiling with the --enable-debug option.  Then run sunbird with the -g option and gdb will allow you to get a stacktrace of the crash, which is one of the most valuable pieces of information for crash bugs.  If possible, please report this stack in a new bug.

ok Joey, will do; I seem to remember the last time I tried I couldn't reproduce it when running under gdb with a non-stripped build, but I'll try again, and log a new bug if I succeed.
logged Bug 321771 to cover the issue in my comment 8; thanks.
bug 329373 may be related, at least the part about skipping the parse for an empty file.
Ever confirmed: true
Whiteboard: [cal relnote]
After doing some more thinking and a bunch of relnote work, I think this needs to block 0.1.  Since we go so far out of our way to say that we're only guaranteed to work with ICS that we generated, not having the most common method of creating ICS files work seems really painful.  Note that the patch in bug 329373 doesn't seem to make a difference here.  Offhand, I would guess that's because instead of an empty string, we're seeing an HTML error page.
Whiteboard: [cal relnote]
The fix for this bug is pretty easy once the patch fox bug 326116 lands.
Depends on: 326116
Attached patch ignore 404 (obsolete) — Splinter Review
Assignee: mostafah → mvl
Attachment #214118 - Flags: first-review?(dmose)
This patch makes the ics provider ignore 404 return code, assuming that the user wanted to create a new calendar.
I'm working on improving the wizard, to warn the user about the creation of a new file. For now, we can do with just the backend.
Attachment #214118 - Attachment is obsolete: true
Attachment #214119 - Flags: first-review?(dmose)
Attachment #214118 - Flags: first-review?(dmose)
Comment on attachment 214119 [details] [diff] [review]
ignore 404, try 2

Attachment #214119 - Flags: first-review?(dmose) → first-review+
Fix landed; thanks for the patch!
Closed: 18 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.