User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Build Identifier: Lightning 0.9pre 2008-07-29 19 / Thunderbird 2.0.0.16 / WinXP I believe that bug 437939 ("Invitation counter needs restart for update") introduced behavior that causes Lightning to use a noticeable amount of CPU every three minutes. It's more of a problem on one of my slower computers: 1.0 GHz CPU: 60% usage for about two seconds 2.8 GHz CPU: 10% usage for about one second It might seem minor, but it's annoying because it interrupts my concentration every three minutes. While I suppose that it won't matter in the future when everyone has faster CPUs, I generally don't like the idea of having no control when one of my apps wants to do something in the background every three minutes, especially when I don't even use WCAP. So I propose the following possible solutions: 1) A different implementation that only does this when invitations have been added/removed. 2) Or disable it for people like me who don't use WCAP calendars. 3) Or disable it if we've disabled the menu setting: "View > Invitations". This might be difficult since this setting is in three different modes: mail, calendar, tasks. 4) Or a user pref to set how often this happens, with a special value to disable it completely. Reproducible: Always

The counter also works on none-wcap calendars. It counts the invitations in your inbox (perhaps other folders too?) plus all other ivitations which have a PARTSTAT=NEEDS-ACTION set fore your account.

I can't reproduce this, Bas. When I receive iMIP emails in my Thunderbird Inbox, the Invitations Link always says, "Invitations (0)". When I click on the link the dialog says, "No unconfirmed invitations found". I'm actually happy about this because I certainly wouldn't want Lightning to search for invitations through the thousands of emails in my Thunderbird mailboxes every three minutes. That would be horribly inefficient. In any case, even if Lightning does search through my inbox every three minutes, I would definitely like to have a way to disable the Invitations Link and all of its related processing. I'm always aware of any invitations that I receive in emails, and the Invitations Link is IMO superfluous and a waste of computer processing for ICS calendars. However, I do understand that it's useful for WCAP and other providers that (as far as I know) don't send invitations by email.

We may consider excluding ics and storage calendars from the invitation dialog, since those are the ones that could only be fed via iTIP/iMIP, and iTIP/iMIP invitations are answered right from the inbox. Though there's still the possibility that users switch back a once accepted invitation to "I will confirm later." using the readonly dialog, and won't see those undecided invitations in the dialog. Moreover because I assume we need to live with polling for some time, we may spend a pref for update cycles similar to the views auto update, e.g. "calendar.invitations.autorefresh.timeout".

prefs are: "calendar.invitations.autorefresh.enabled" (bool) "calendar.invitations.autorefresh.timeout" (int in minutes) Pete, it would be nice if you could test this patch a bit up front, too.

Comment on attachment 335020 [details] [diff] [review] [checked in] prefs to control autorefresh of invitations link r=philipp

I manually applied the patch but changed this line: }, getPrefSafe("calendar.invitations.autorefresh.timeout", 3) * 1000); to this }, getPrefSafe("calendar.invitations.autorefresh.timeout", 3) * 60000); Then I started TB, changed the refresh pref to one minute (via TB's UI), and restarted TB. As expected, the refresh happened every minute. Then I set "calendar.invitations.autorefresh.enabled" to false and restarted TB. This will be my normal setting. This also worked nicely (no CPU usage anymore), so thanks a lot for this patch (with the minor fix that I mentioned). FWIW, I only tested with local ICS calendars (because I only use those).

Comment on attachment 335020 [details] [diff] [review] [checked in] prefs to control autorefresh of invitations link Yes, we want minutes instead of seconds. Thanks for testing and catching that nit. Checked in on HEAD and MOZILLA_1_8_BRANCH. Leaving bug open for adding UI to control these settings.

I am not a programmer. I am just a regular user that is experiencing this issue with the CPU usage spiking and locking TB up every couple of minutes. I appreciate all the help that several of you have tried to give me so far, but here's my next dilemma. I have no idea what UI is, or what to do with the attachment in comment #4. If someone could reach down to help me out here, I'd be grateful.

(In reply to comment #8) For Lightning 0.9: Open "Tools > Options > Advanced > General > Config Editor...". Set the filter to "calendar.invitations.autorefresh.enabled" and double click the found entry to disable the feature completely (set to false). Or keep it enabled but filter for "calendar.invitations.autorefresh.timeout" and increase the timeout.

Thanks, Stefan, this seems to have fixed a good portion of the CPU usage so far.

(In reply to comment #7) > Leaving bug open for adding UI to control these settings. if the CPU issue is resolved, can the UI issue move to a separate bug and this one closed? ... to better reflect reality

Sure, we can do that. I don't think we need much UI for this. As long as there is a manual refresh button, if the interval isn't enough for people I think we can expect them to modify the advanced prefs. Maybe we can even hook it up to the calendar autorefresh interval.