315511 - New remote calendar is readonly first and a error message appears

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Thorsten]

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).

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

What CalDAV server are you using?

Comment 2

[Thorsten]

Hello,
I used a WebDAV-folder not a CalDAV-server.
I have got reading and writing rights on this WebDAV-folder.
THanks
Thorsten

Comment 3

[Majken Connor [:Kensie]]

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

Comment 4

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

> Errornumber : 0x804a0107

The only place this seems to be able to come from, is http://lxr.mozilla.org/seamonkey/source/calendar/libical/src/libical/icaltimezone.c#1441
And i do see it coming from there, on startup.

Stack:
#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/libcalbasecomps.so

I don't see an easy way around this.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

mvl: Any chance you could get that trace again, but using "where full" on a debug build, and pasting more frames of the stack? 

Comment 6

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

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 zones.tab. But we don't ship zones.tab, so a file-not-found error is thrown.

Comment 7

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

A possible solution might be to comment out http://lxr.mozilla.org/seamonkey/source/calendar/libical/src/libical/icaltimezone.c#1398 but i'm not sure what the results would be. How do we try to handle timezones, and how does libical handle them?

Comment 8

[Calum Mackay]

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/run-mozilla.sh: 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? 

Comment 9

[Joey Minta]

(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.

Comment 10

[Calum Mackay]

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.

Comment 11

[Calum Mackay]

logged Bug 321771 to cover the issue in my comment 8; thanks.

Comment 12

[gekacheka]

bug 329373 may be related, at least the part about skipping the parse for an empty file.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 14

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

The fix for this bug is pretty easy once the patch fox bug 326116 lands.

Comment 15

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

Attachment: ignore 404

Comment 16

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

Attachment: ignore 404, try 2

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.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 214119 [details] [diff] [review]
ignore 404, try 2

r=dmose

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

Fix landed; thanks for the patch!