New remote calendar is readonly first and a error message appears

RESOLVED FIXED

Status

RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: thorsten, Assigned: mvl)

Tracking

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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?
(Reporter)

Comment 2

13 years ago
Hello,
I used a WebDAV-folder not a CalDAV-server.
I have got reading and writing rights on this WebDAV-folder.
THanks
Thorsten
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
(Assignee)

Comment 4

13 years ago
> 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.
mvl: Any chance you could get that trace again, but using "where full" on a debug build, and pasting more frames of the stack? 
(Assignee)

Comment 6

13 years ago
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.
(Assignee)

Comment 7

13 years ago
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

13 years ago
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

13 years ago
(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

13 years ago
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

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

Comment 12

13 years ago
bug 329373 may be related, at least the part about skipping the parse for an empty file.
Status: UNCONFIRMED → NEW
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.
Blocks: 298366
Whiteboard: [cal relnote]
(Assignee)

Comment 14

13 years ago
The fix for this bug is pretty easy once the patch fox bug 326116 lands.
Depends on: 326116
(Assignee)

Comment 15

13 years ago
Created attachment 214118 [details] [diff] [review]
ignore 404
Assignee: mostafah → mvl
Status: NEW → ASSIGNED
Attachment #214118 - Flags: first-review?(dmose)
(Assignee)

Comment 16

13 years ago
Created attachment 214119 [details] [diff] [review]
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.
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

r=dmose
Attachment #214119 - Flags: first-review?(dmose) → first-review+
Fix landed; thanks for the patch!
Status: ASSIGNED → RESOLVED
Last Resolved: 13 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.