246091 - Calendar hangs indefinitely on startup as of 08-Jun-2004, two different machines

Status: RESOLVED WORKSFORME

(Calendar :: General, defect)

Description

[Ian Batterbee]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040608

Since the 8th of June, the calendar has hung on startup, on two different
machines that I use to access the same remote .ics file.

Some of the UI still responds, but for the most part I can't do anything.

I can click on the Calendars tab, and see that the little red arrow thing is
going round and round trying to read my calendar ics file from a webserver. I
can also access the menus and icons at the top, but nothing at all happens when
I select any of them.

I have performed the following troubleshooting, in the order listed below.

I ran ethereal and packet traced the conversation. The .ics file is sucessfully
and completely retrieved, and the TCP session is closed and the close
acknowledged. Nevertheless, the little red 'loading' icon still shows and animates.

I renamed the .ics file so it was not accessible. This caused calendar to
complain that what it got back didn't look like an ICS file (it got a 404 not
found message), I was able to click ok on that diaglog, but then we're back to
square one, with the red loading icon going, and an unresponsive UI.

I closed mozilla, and renamed the profiles\...\calendar directory and restarted
mozilla. This caused it to start up with no calendars available, but I was still
not able to interact with the calendar.

I successfully opened the same .ics file using a php based ical viewer from 
http://phpicalendar.sourceforge.net/nuke/

In all cases, if I close the calendar window with the X in the top right corner,
mozilla crashes.

I installed mozilla 1.7 rc3 over the top of RC2, then reinstalled the calendar
from www.mozilla.org/projects/calendar. This made no difference at all.

Note that this happened simultanously on two different computers (one at work,
one at home). Both machines are running W2K and MS update patches and
servicepacks are up to date. From that, I figured it must be a corrupt .ICS
file, but given that it still fails without even trying to access the file, it
can't be just that.

I guess the next step would be to trash my entire mozilla profile and start
again.. but I'm reluctant to do that as it takes so long to get mozilla back the
way I like it, and by renaming the calendar/ subdirectory, I would have thought
I have already cleared any possibly calendar settings.

I would appreciate any ideas that people may have to try and pinpoint the cause
of this problem.


Reproducible: Always
Steps to Reproduce:





I will update this bug with the crash info when I close the calendar window once
I've submitted this form.

Comment 1

[Mostafa Hosseini]

There's a new *test* build available at
http://ftp.mozilla.org/pub/mozilla.org/calendar/xpi/windows/calendar_windows_20040609.xpi

can you try it to see if it fixes the problem?

Comment 2

[Ian Batterbee]

damn.. I can't post the crash info because nothing appeared in the event log, or
in the drwatson log.  I did install the talkback agent, and have the info from
there, but it's too big to post into this bug. I submitted it anyway and tagged
it with this bugid in the 'what were you doing' field.

Answering the previous question - I installed the test build of calendar, and it
acts a little differently.. it asked for my login and password for the webserver
- presumably it cleared the old cached info out. I gave it that, and it got a
404 (because the .ics is still renamed), and it has displayed the locally cached
events on my calendar okay now (the older version displayed no information at
all in the calendar view - just empty days)

I was then able to interact with the events in the calendar, but the 'loading'
icon is still rotating.

I then told it to publist my current calendar to the remote .ics file (and
there's another bug there too - the progress bar never updates.. the button just
changes from 'publish' to 'close', and I have to assume that it succeeded).

I then refreshed the remote calendar, and the loading icon stopped rotating.

I then added a new event, waited 5 seconds, then refreshed the calendar again,
and the event survived the reload, and I checked the datetime on the filesystem
of the webserver, and confirmed it had been updated.

So far so good. Thanks for the update ! :)

Any idea what caused it, or why it happened to both machines at the same time ?

Comment 3

[Ian Batterbee]

Also, regarding the test build I'm now running - if I go help / about, the
dialog box it creates has zero height. I can drag the bottom border and make it
visible, but it forgets it again the next time I open help/about.

Comment 4

[Martin Bagge / brother]

this sounds pretty serious but have you (the reporter) some issues with it still?

Comment 5

[Matthew (lilmatt) Willis]

Reporter,
We cannot continue working on this bug without your response to the above query.
Please respond within 5 days. Otherwise this bug will be marked as INVALID.

Comment 6

[JD]

(In reply to comment #5)
> Reporter,
> We cannot continue working on this bug without your response to the above 
query.
> Please respond within 5 days. Otherwise this bug will be marked as INVALID.

A co-worker of mine is having similar problems. And as of today, I can no 
longer load one of my calendars. The only thing that is unique about it vs. the 
other 10 I have it that it's file size is double the others (63k vs <=30). Is 
it possible that the Calendar program has a problem parsing information larger 
than 60k or so?

Comment 7

[Mostafa Hosseini]

(In reply to comment #6)

> Is it possible that the Calendar program has a problem parsing information 
> larger than 60k or so?

There used to be a bug about this but it got fixed. What version of the calendar
are you running?
If you remove the file does calendar work again? If so, you have to find the
specific event that is causing this.

Comment 8

[Joey Minta]

The original bug issue is WFM, and no clarification was received after requests
from Martin and lilmatt.  In reply to comment #6, the bug dealing with ics file
size limits is bug 284095.

Comment 9

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!