User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 The events from one of my calendars had disappeared from Lightning. I right-clicked in the calendar list and told it to "Reload Remote Calendars" but the events were still missing. I then unchecked and rechecked the box for that calendar. All events from all calendars then disappeared. My status bar reads "Checking Calendar 6 of 4294967302". If I tell Thunderbird to quit, the window disappears but the process remains running and must be forcefully terminated. Reproducible: Couldn't Reproduce
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:126.96.36.199) Gecko/20101207 Lightning/1.0b3pre Thunderbird/3.1.7 ----- i am also experiencing lightning hanging on OS X on calendar reloads. migrating comments from http://weblogs.mozillazine.org/calendar/2010/12/lightning_10b3pre_now_with_num.html: tb 3.1.7 + lightning 1.0b3pre is exhibiting cpu-hogging + hanging behavior on multiple, various sources, calendar reload. witnessed it both on win7 and os x leopard. after only leaving 5 caldav (server: davical) calendars enabled, hanging seems to have stopped. last hanging behavior happened when i also enabled (=switch on) a single ICS facebook event feed calendar. will debug further. ----- yeah no good, came back tonight after leaving TB idle for the day and it had hung on reloading the calendars, which can be identified from the fact that the whole calendar is in clear-just-before-refresh state. (this is after disabling all ICS calendars for testing) -EOF- attaching hangreport.
hang on windows again when multiple CalDAV + ICS calendars are enabled. process explorer shows the cpu hogging Thread Start Address as: thunderbird!?TransformCoord@nsTransform2D@@QBEXPAH000@Z stack inside this thread is: thunderbird.exe!DumpJSEval+0x9013e thunderbird.exe!DumpJSEval+0x92816 thunderbird.exe!DumpJSEval+0x922d4
this is still happening on both OS X and Windows 7. it appears that many CalDAV + many Google Calendars work stable, but as soon as I add Facebook events' ICS feed, it will hang on next automatic reload.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b13pre) Gecko/20110314 Thunderbird/3.3a3 Lightning Build ID: 20110320030832 Google Calendar Provider 0.8pre from the same day i have upgraded yesterday from 3.1.9 to miramar 3.3a3 and lightning 1.0b4pre. this problem still exists in full form, i'm now almost 100% certain it's a problem within automatic reload mechanism. of course, this is a conclusion without any thorough debugging tools. i have 5 caldav calendars and 3 google calendars subscribed. after inital upgrade, i watched miramar hang at the first reload cycle of 30 minutes. after seeing this, i switched off automatic reload on google calendars. this made miramar run stable whole day long. at night i put the mac to sleep. mac automatically woke up this morning and reconnected to the network. this seems to trigger a reload cycle for all calendar and miramar hung again. i'm attaching a sample from the hung process.
The large stack reminds me of bug 494788. Could you apply the patch on that bug and see if it still hangs?
this patch has me running stable for at least two weeks now, thanks a million. did you integrate it into nightlies yet based on occasional our irc exchanges?
It hasen't been integrated due to lack of review, I'm working on it though!
I have found that Lightning slows Thunderbird if the calendar search is set to "All Events", since my calendar goes back a long way, and it takes several seconds to load. If I leave the calendar search on "Today's Events" (except when I want to a broader search), the delay disappears.
I'm experiencing TB UI completely freezing until my calendar refreshes are done. CPU usage is quite high at the time. I am not sure what to do with this, this bug came to mind first. Joe's note is very interesting, I'm setting the Find box to Today's Events now as well and seeing what happens. I remember when we were debugging this with :Fallen, some changes ended up in Lightning threading model and does feel like some sort of a threading problem, where Lightning just clogs the main UI thread up. But I will hold off on opening a new bug until I find out about whether the Find box (which I actually have hidden by default, so definitely possible bug material) affects anything.
@version TB 13.0.1, Lightning 1.5.2
I had this problem, then didn't notice this for some time, but now it's back. It's particularly troublesome while I'm writing an email - the composer window freezes for several seconds, is moved to the background or hidden, and keystrokes are lost. Presently running TB 17.0.5 on Win XP, with Lightning 1.9.1, Exchange 2007/2010 Calendar and Tasks Provider 3.1.102 and Provider for Google Calendar 0.18. I can't say that the Exchange or Google caledars are noticably the problem, it looks more like my 5 FTP-remote calendars are causing at least as much delay (one of these remote calendars is about 75 kB). I have to question the assignment of this as a duplicate to Bug 474788, which I also had affect me but only on startup and the only noticable symptom were console messages and deferred loading of remote calendars. This is different.
I moved my calendars into a separate profile. Everything is ahem lightning fast now for both mail and calendaring.
Fallen: I don't think this bug was a duplicate and it certainly hasn't gone away on its own, per my Comment 14 and macmaN's Comment 15. Users shouldn't have to switch profiles to work around this bug. What do you think about reopening?
I don't think we should reopen, the codebase has changed a lot since 2010. The scope of this bug is quite general, Lightning's performance during reloads is not so great. There is probably no single patch that would fix this bug, I rather suspect a combination of many different patches, all regarding separate issues. There is a Summer of Code Project suggested for this year regarding performance, maybe its something you want to consider. Please see the following bugs for alternative duplicates: bug 592876, bug 841995, bug 733039.