Thunderbird 12.0.1 locks up when this add-in is enabled

573 views
Skip to first unread message

Ciro Ramirez

unread,
May 30, 2012, 11:21:15 AM5/30/12
to provider-for-g...@googlegroups.com
I have been using Thunderbird/Lightning/Provider for Google calendar successfully for many months.  For the last week (I think since Thunderbird 12.0.1 was released), I cannot start Thunderbird - it freezes on startup, and does not permit any selections, including getting e-mail.  If I disable the Google Provider for Lightning, I can start and run normally.  Any ideas?  Should I also post this on the Thunderbird forum?

Michael Secord

unread,
May 31, 2012, 9:03:22 AM5/31/12
to provider-for-g...@googlegroups.com, Ciro Ramirez
I've noticed a lot of responsiveness issues lately with the Tbird 12 and
latest provider/lightning. I haven't tested without provider, but it
seems to reside there. For instance, Tbird will run just fine until I
try to create a new calendar appointment, at which point it takes 10+
seconds to respond every time I start typing in one.

On 5/30/2012 11:21 AM Ciro Ramirez <ciro.r...@gmail.com> said unto
provider-for-g...@googlegroups.com:
> --
> You received this message because you are subscribed to the Google
> Groups "Provider for Google Calendar" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/provider-for-google-calendar/-/ipFNN73UtV4J.
> To post to this group, send email to
> provider-for-g...@googlegroups.com.
> To unsubscribe from this group, send email to
> provider-for-google-...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/provider-for-google-calendar?hl=en.

Lewis G Rosenthal

unread,
May 31, 2012, 9:26:31 AM5/31/12
to provider-for-g...@googlegroups.com
Good morning...

On 05/31/12 09:03 am, Michael Secord thus wrote :
> I've noticed a lot of responsiveness issues lately with the Tbird 12
> and latest provider/lightning. I haven't tested without provider, but
> it seems to reside there. For instance, Tbird will run just fine until
> I try to create a new calendar appointment, at which point it takes
> 10+ seconds to respond every time I start typing in one.
>
The problem, of course, is that as Provider relies on a responsive
connection to Google, it's hard to tell whether the problem is local to
the machine, related to TB (or SeaMonkey), Lightning, or the Provider
build, *or* whether Google may have - in its infinite wisdom - changed
something on its end.

Any time we need to connect with (and maintain that connection to) a
third party, there are a great number of additional factors which come
into play.

Do you notice a difference if you enable caching? Presently, I'm using
Provider version 0.16pre. I do experience some slow startup, but by far
what can bring my computer to a stop is gContactSync. Some days, I
disable it. Setting it active again later on or the next day, things are
usually better.
> On 5/30/2012 11:21 AM Ciro Ramirez <ciro.r...@gmail.com> said unto
> provider-for-g...@googlegroups.com:
>> I have been using Thunderbird/Lightning/Provider for Google calendar
>> successfully for many months. For the last week (I think since
>> Thunderbird 12.0.1 was released), I cannot start Thunderbird - it
>> freezes on startup, and does not permit any selections, including
>> getting e-mail. If I disable the Google Provider for Lightning, I
>> can start and run normally. Any ideas? Should I also post this on
>> the Thunderbird forum?
>>
I wouldn't cross-post this to the TB forum, Ciro. Instead, the same
question applies here as I posed to Michael: Any difference whether you
have caching enabled or not?

Also, for both of you, what version of Provider are you running, and
what version of Lightning?

Just trying to get a sense of what constants there are with this bad
behavior.

Cheers

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC www.2rosenthals.com
Need a managed Wi-Fi hotspot? www.hautspot.com
visit my IT blog www.2rosenthals.net/wordpress
please do not add my address to any non-bcc mass mailings
-------------------------------------------------------------

Michael Secord

unread,
May 31, 2012, 9:55:51 AM5/31/12
to provider-for-g...@googlegroups.com, Lewis G Rosenthal
Thanks for the reply Lewis..

On 5/31/2012 9:26 AM Lewis G Rosenthal <lgros...@2rosenthals.com>
said unto provider-for-g...@googlegroups.com:

> Good morning...
>
> On 05/31/12 09:03 am, Michael Secord thus wrote :
>> I've noticed a lot of responsiveness issues lately with the Tbird 12
>> and latest provider/lightning. I haven't tested without provider, but
>> it seems to reside there. For instance, Tbird will run just fine until
>> I try to create a new calendar appointment, at which point it takes
>> 10+ seconds to respond every time I start typing in one.
>>
> The problem, of course, is that as Provider relies on a responsive
> connection to Google, it's hard to tell whether the problem is local to
> the machine, related to TB (or SeaMonkey), Lightning, or the Provider
> build, *or* whether Google may have - in its infinite wisdom - changed
> something on its end.

As such problems usually are, can easily be attributed to multiple
causes, some of which we have no control over...

The only thing I can add to this, is I've had it happen on 3 different
machines, across 2 different operating systems, 2 different locations,
and 4 different network setups, and it always comes back to the same issue.

>
> Any time we need to connect with (and maintain that connection to) a
> third party, there are a great number of additional factors which come
> into play.
>
> Do you notice a difference if you enable caching? Presently, I'm using
> Provider version 0.16pre. I do experience some slow startup, but by far
> what can bring my computer to a stop is gContactSync. Some days, I
> disable it. Setting it active again later on or the next day, things are
> usually better.

Enabling cache seems to have helped thus far with the few events I had
to add this morning.

The odd thing, is I never notice any problems on startup, just when I
try to do something with the calendar, such as add an event...

>> On 5/30/2012 11:21 AM Ciro Ramirez<ciro.r...@gmail.com> said unto
>> provider-for-g...@googlegroups.com:
>>> I have been using Thunderbird/Lightning/Provider for Google calendar
>>> successfully for many months. For the last week (I think since
>>> Thunderbird 12.0.1 was released), I cannot start Thunderbird - it
>>> freezes on startup, and does not permit any selections, including
>>> getting e-mail. If I disable the Google Provider for Lightning, I
>>> can start and run normally. Any ideas? Should I also post this on
>>> the Thunderbird forum?
>>>
> I wouldn't cross-post this to the TB forum, Ciro. Instead, the same
> question applies here as I posed to Michael: Any difference whether you
> have caching enabled or not?
>
> Also, for both of you, what version of Provider are you running, and
> what version of Lightning?

Lightning 1.4
Provider for Google Calendar 0.13

>
> Just trying to get a sense of what constants there are with this bad
> behavior.
>
> Cheers
>

Thanks!

-Michael

Lewis G Rosenthal

unread,
May 31, 2012, 10:39:09 AM5/31/12
to provider-for-g...@googlegroups.com
On 05/31/12 09:55 am, Michael Secord thus wrote :
> Thanks for the reply Lewis..
>
Surely, Michael; my pleasure.
> On 5/31/2012 9:26 AM Lewis G Rosenthal <lgros...@2rosenthals.com>
> said unto provider-for-g...@googlegroups.com:
>
>> Good morning...
>>
>> On 05/31/12 09:03 am, Michael Secord thus wrote :
>>> I've noticed a lot of responsiveness issues lately with the Tbird 12
>>> and latest provider/lightning. I haven't tested without provider, but
>>> it seems to reside there. For instance, Tbird will run just fine until
>>> I try to create a new calendar appointment, at which point it takes
>>> 10+ seconds to respond every time I start typing in one.
>>>
>> The problem, of course, is that as Provider relies on a responsive
>> connection to Google, it's hard to tell whether the problem is local to
>> the machine, related to TB (or SeaMonkey), Lightning, or the Provider
>> build, *or* whether Google may have - in its infinite wisdom - changed
>> something on its end.
>
> As such problems usually are, can easily be attributed to multiple
> causes, some of which we have no control over...
>
> The only thing I can add to this, is I've had it happen on 3 different
> machines, across 2 different operating systems, 2 different locations,
> and 4 different network setups, and it always comes back to the same
> issue.
>
Well, that probably eliminates hardware, operating systems, network
connections, and broadband. Are the TB, Lighting, and Provider versions
the same between the two? I'm assuming (dangerous to assume) that both
of these systems are connecting to the same Google calendar(s) and that
other elements of their configuration are similar (number of email
accounts, extension mix, etc.).
>>
>> Any time we need to connect with (and maintain that connection to) a
>> third party, there are a great number of additional factors which come
>> into play.
>>
>> Do you notice a difference if you enable caching? Presently, I'm using
>> Provider version 0.16pre. I do experience some slow startup, but by far
>> what can bring my computer to a stop is gContactSync. Some days, I
>> disable it. Setting it active again later on or the next day, things are
>> usually better.
>
> Enabling cache seems to have helped thus far with the few events I had
> to add this morning.
>
AIUI, caching should help deal with situations where there are delays on
the server side. However, I've seen instances where caching brings about
other performance drawbacks, so I'm glad to hear that so far, this is
working on the positive side for you.
> The odd thing, is I never notice any problems on startup, just when I
> try to do something with the calendar, such as add an event...
>
...which is when you would be most likely to see a slowdown, as that's
when the sync takes place. Do you have a number of alarms set or
recurring events?
>>> On 5/30/2012 11:21 AM Ciro Ramirez<ciro.r...@gmail.com> said unto
>>> provider-for-g...@googlegroups.com:
>>>> I have been using Thunderbird/Lightning/Provider for Google calendar
>>>> successfully for many months. For the last week (I think since
>>>> Thunderbird 12.0.1 was released), I cannot start Thunderbird - it
>>>> freezes on startup, and does not permit any selections, including
>>>> getting e-mail. If I disable the Google Provider for Lightning, I
>>>> can start and run normally. Any ideas? Should I also post this on
>>>> the Thunderbird forum?
>>>>
>> I wouldn't cross-post this to the TB forum, Ciro. Instead, the same
>> question applies here as I posed to Michael: Any difference whether you
>> have caching enabled or not?
>>
>> Also, for both of you, what version of Provider are you running, and
>> what version of Lightning?
>
> Lightning 1.4
> Provider for Google Calendar 0.13
>
You might want to try a nightly build, just for the heck of it. Frankly,
though, I haven't seen much performance difference between 0.11 and 0.16pre.
>>
>> Just trying to get a sense of what constants there are with this bad
>> behavior.
>>
>> Cheers
>>
>
> Thanks!
>
You bet!

Michael Secord

unread,
May 31, 2012, 10:47:54 AM5/31/12
to provider-for-g...@googlegroups.com


On 5/31/2012 10:39 AM Lewis G Rosenthal <lgros...@2rosenthals.com>
Versions are the same between them all, one of the machines and the
alternate os (OSX) runs a different setup than the other machines (I use
TBird portable across them all), in that it only has 1 account and
hardly any extensions outside of Lightning and Provider.

It is a good assumption that it's all with the same google calendar on
the same google account though.
>>> Any time we need to connect with (and maintain that connection to) a
>>> third party, there are a great number of additional factors which come
>>> into play.
>>>
>>> Do you notice a difference if you enable caching? Presently, I'm using
>>> Provider version 0.16pre. I do experience some slow startup, but by far
>>> what can bring my computer to a stop is gContactSync. Some days, I
>>> disable it. Setting it active again later on or the next day, things are
>>> usually better.
>> Enabling cache seems to have helped thus far with the few events I had
>> to add this morning.
>>
> AIUI, caching should help deal with situations where there are delays on
> the server side. However, I've seen instances where caching brings about
> other performance drawbacks, so I'm glad to hear that so far, this is
> working on the positive side for you.
>> The odd thing, is I never notice any problems on startup, just when I
>> try to do something with the calendar, such as add an event...
>>
> ...which is when you would be most likely to see a slowdown, as that's
> when the sync takes place. Do you have a number of alarms set or
> recurring events?
I almost never use alarms in the calendar, but there are a few recurring
events scattered throughout the calendar. It just seems to happen after
I open the calendar, then double-click to add a new entry and after I
enter 1 or 2 characters (not sure if this is actually a trigger, I Just
start typing right away so I don't know for sure) it will hang for ~10s,
then come back for ~1-2s, then hang again. At this point though I'm
usually done entering and just save it, so I don't know if the loop
continues.
>>>> On 5/30/2012 11:21 AM Ciro Ramirez<ciro.r...@gmail.com> said unto
>>>> provider-for-g...@googlegroups.com:
>>>>> I have been using Thunderbird/Lightning/Provider for Google calendar
>>>>> successfully for many months. For the last week (I think since
>>>>> Thunderbird 12.0.1 was released), I cannot start Thunderbird - it
>>>>> freezes on startup, and does not permit any selections, including
>>>>> getting e-mail. If I disable the Google Provider for Lightning, I
>>>>> can start and run normally. Any ideas? Should I also post this on
>>>>> the Thunderbird forum?
>>>>>
>>> I wouldn't cross-post this to the TB forum, Ciro. Instead, the same
>>> question applies here as I posed to Michael: Any difference whether you
>>> have caching enabled or not?
>>>
>>> Also, for both of you, what version of Provider are you running, and
>>> what version of Lightning?
>> Lightning 1.4
>> Provider for Google Calendar 0.13
>>
> You might want to try a nightly build, just for the heck of it. Frankly,
> though, I haven't seen much performance difference between 0.11 and 0.16pre.
The last few times I've tried nightly builds of Lightning/Provider, it
all just stopped working entirely...so I'm a bit hesitant, though it's
likely that the Lightning nightly was the cause, not Provider..
>>> Just trying to get a sense of what constants there are with this bad
>>> behavior.
>>>
>>> Cheers
>>>
>> Thanks!
>>
> You bet!
>
-Michael

Lewis G Rosenthal

unread,
May 31, 2012, 11:18:09 AM5/31/12
to provider-for-g...@googlegroups.com
Hi, again...

On 05/31/12 10:47 am, Michael Secord thus wrote :
>
>
> On 5/31/2012 10:39 AM Lewis G Rosenthal <lgros...@2rosenthals.com>
> said unto provider-for-g...@googlegroups.com:
>> On 05/31/12 09:55 am, Michael Secord thus wrote :
>>> Thanks for the reply Lewis..
>>>
>> Surely, Michael; my pleasure.
>>> On 5/31/2012 9:26 AM Lewis G Rosenthal<lgros...@2rosenthals.com>
>>> said unto provider-for-g...@googlegroups.com:
>>>
>>>> Good morning...
>>>>
>>>> On 05/31/12 09:03 am, Michael Secord thus wrote :
>>>>
<snip>
>>>>
>>> As such problems usually are, can easily be attributed to multiple
>>> causes, some of which we have no control over...
>>>
>>> The only thing I can add to this, is I've had it happen on 3 different
>>> machines, across 2 different operating systems, 2 different locations,
>>> and 4 different network setups, and it always comes back to the same
>>> issue.
>>>
>> Well, that probably eliminates hardware, operating systems, network
>> connections, and broadband. Are the TB, Lighting, and Provider versions
>> the same between the two? I'm assuming (dangerous to assume) that both
>> of these systems are connecting to the same Google calendar(s) and that
>> other elements of their configuration are similar (number of email
>> accounts, extension mix, etc.).
> Versions are the same between them all, one of the machines and the
> alternate os (OSX) runs a different setup than the other machines (I
> use TBird portable across them all), in that it only has 1 account and
> hardly any extensions outside of Lightning and Provider.
>
That's good (few extensions). Invariably, I need to either disable all
of mine for testing or use a fresh profile, which is always a pain to
set up.
> It is a good assumption that it's all with the same google calendar on
> the same google account though.
>
Good. The more similarities, the better (obviously).

<snip>
>> Do you have a number of alarms set or
>> recurring events?
> I almost never use alarms in the calendar, but there are a few
> recurring events scattered throughout the calendar. It just seems to
> happen after I open the calendar, then double-click to add a new entry
> and after I enter 1 or 2 characters (not sure if this is actually a
> trigger, I Just start typing right away so I don't know for sure) it
> will hang for ~10s, then come back for ~1-2s, then hang again. At this
> point though I'm usually done entering and just save it, so I don't
> know if the loop continues.
>
Interesting. I'll keep an eye on mine to see if I experience anything
similar. Thanks for the additional detail, which always helps.

I use a fair amount of alarms, and I have a couple monthly recurring
events. Calendar startup can be slow for me - at times. The
inconsistency of it leads me to believe that the problem is on Google's
side of the connection (ditto for gContactSync, which seems to be
behaving well thus far today).

If you open the calendar and then just browse around, without making an
entry, how does it behave? When you switch views to say, weekly or
monthly, and then back again, does that make a difference?

Finally (as I'm thinking about it), do you have any read-only remote
calendars which are using CalDAV and not Provider? I have several of
these for holidays and such. Loading these up sometimes can take some
resources (but would have little or no bearing on entering events,
obviously). I should turn these off and see how calendar startup time is
after a restart of SeaMonkey. This might account for doifferences
between the two of us insofar as startup is concerned (which is where I
see the greatest lag, and you apparently don't).

<snip>
>>>> Also, for both of you, what version of Provider are you running, and
>>>> what version of Lightning?
>>> Lightning 1.4
>>> Provider for Google Calendar 0.13
>>>
>> You might want to try a nightly build, just for the heck of it. Frankly,
>> though, I haven't seen much performance difference between 0.11 and
>> 0.16pre.
> The last few times I've tried nightly builds of Lightning/Provider, it
> all just stopped working entirely...so I'm a bit hesitant, though it's
> likely that the Lightning nightly was the cause, not Provider..
>
I understand. I agree, however, that upgrading Provider is probably less
problematic (at least to 0.16pre, as I'm using) than a new Lightning
build. On OS/2, our latest Lightning is 1.2.3, and Provider 0.16pre runs
fine under that. I'm fairly certain that you should have no issues with it.

Michael Secord

unread,
Jun 4, 2012, 11:39:51 AM6/4/12
to provider-for-g...@googlegroups.com


On 5/31/2012 11:18 AM Lewis G Rosenthal <lgros...@2rosenthals.com>
I can't say I've seen many differences in that. Before I cached it would
take ~1-2s to refresh the calendar, which I never thought was out of the
ordinary for the sheer number of events that exist on my calendar. Now
it's typically <1s to refresh with the cache.

>
> Finally (as I'm thinking about it), do you have any read-only remote
> calendars which are using CalDAV and not Provider? I have several of
> these for holidays and such. Loading these up sometimes can take some
> resources (but would have little or no bearing on entering events,
> obviously). I should turn these off and see how calendar startup time is
> after a restart of SeaMonkey. This might account for doifferences
> between the two of us insofar as startup is concerned (which is where I
> see the greatest lag, and you apparently don't).

I do, I have the US holidays calendar and a WUnderground weather
calendar that are also used, but there doesn't seem to be any
differences whether or not they're enabled.

>
> <snip>
>>>>> Also, for both of you, what version of Provider are you running, and
>>>>> what version of Lightning?
>>>> Lightning 1.4
>>>> Provider for Google Calendar 0.13
>>>>
>>> You might want to try a nightly build, just for the heck of it. Frankly,
>>> though, I haven't seen much performance difference between 0.11 and
>>> 0.16pre.
>> The last few times I've tried nightly builds of Lightning/Provider, it
>> all just stopped working entirely...so I'm a bit hesitant, though it's
>> likely that the Lightning nightly was the cause, not Provider..
>>
> I understand. I agree, however, that upgrading Provider is probably less
> problematic (at least to 0.16pre, as I'm using) than a new Lightning
> build. On OS/2, our latest Lightning is 1.2.3, and Provider 0.16pre runs
> fine under that. I'm fairly certain that you should have no issues with it.
>

So..digging through, I'm not sure which directory I should be digging in
for the nightly stuff...

Lewis G Rosenthal

unread,
Jun 4, 2012, 2:02:10 PM6/4/12
to provider-for-g...@googlegroups.com
Hey...

On 06/04/12 11:39 am, Michael Secord thus wrote :
A recent bug comment seemed to indicate that someone was experiencing
the momentary "hang" issue without Provider in use, so it may be
something else entirely. I need to turn caching back on to see how it
behaves for me. I'll do that when I get done with this reply.
>>
>> Finally (as I'm thinking about it), do you have any read-only remote
>> calendars which are using CalDAV and not Provider? I have several of
>> these for holidays and such. Loading these up sometimes can take some
>> resources (but would have little or no bearing on entering events,
>> obviously). I should turn these off and see how calendar startup time is
>> after a restart of SeaMonkey. This might account for doifferences
>> between the two of us insofar as startup is concerned (which is where I
>> see the greatest lag, and you apparently don't).
>
> I do, I have the US holidays calendar and a WUnderground weather
> calendar that are also used, but there doesn't seem to be any
> differences whether or not they're enabled.
>
And you're using those via Provider or via CalDAV (just to be sure)? All
of my read-only calendars are CalDAV. That said, you answered my next
question in advance, by mentioning that you see no change with them
disabled.
>>
>> <snip>
>>>>>> Also, for both of you, what version of Provider are you running, and
>>>>>> what version of Lightning?
>>>>> Lightning 1.4
>>>>> Provider for Google Calendar 0.13
>>>>>
>>>> You might want to try a nightly build, just for the heck of it.
>>>> Frankly,
>>>> though, I haven't seen much performance difference between 0.11 and
>>>> 0.16pre.
>>> The last few times I've tried nightly builds of Lightning/Provider, it
>>> all just stopped working entirely...so I'm a bit hesitant, though it's
>>> likely that the Lightning nightly was the cause, not Provider..
>>>
>> I understand. I agree, however, that upgrading Provider is probably less
>> problematic (at least to 0.16pre, as I'm using) than a new Lightning
>> build. On OS/2, our latest Lightning is 1.2.3, and Provider 0.16pre runs
>> fine under that. I'm fairly certain that you should have no issues
>> with it.
>>
>
> So..digging through, I'm not sure which directory I should be digging
> in for the nightly stuff...
>
Try
http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/1.5b2-candidates/build1/linux/gdata-provider.xpi
(it appears that you're on Windows, though the platform should not
matter - just don't try to install the nightly lightning.xpi from there,
though, as Lightning includes platform-specific binaries).

As always, remember that the nightly is still a "test" version, and you
may find other unpleasant things in it. The last nightly I installed has
been working well for me, though, but that's all I can say about it.
Give it a shot, and if it makes things worse or causes other things,
then roll back.

Cheers

Michael Secord

unread,
Jun 4, 2012, 2:16:17 PM6/4/12
to provider-for-g...@googlegroups.com


On 6/4/2012 2:02 PM Lewis G Rosenthal <lgros...@2rosenthals.com> said
unto provider-for-g...@googlegroups.com:
> Hey...
>
> On 06/04/12 11:39 am, Michael Secord thus wrote :
>>
>> On 5/31/2012 11:18 AM Lewis G Rosenthal<lgros...@2rosenthals.com>
>> said unto provider-for-g...@googlegroups.com:
<snip>
I did notice that once or twice, but only on my Mac, never on windows...

>>> Finally (as I'm thinking about it), do you have any read-only remote
>>> calendars which are using CalDAV and not Provider? I have several of
>>> these for holidays and such. Loading these up sometimes can take some
>>> resources (but would have little or no bearing on entering events,
>>> obviously). I should turn these off and see how calendar startup time is
>>> after a restart of SeaMonkey. This might account for doifferences
>>> between the two of us insofar as startup is concerned (which is where I
>>> see the greatest lag, and you apparently don't).
>> I do, I have the US holidays calendar and a WUnderground weather
>> calendar that are also used, but there doesn't seem to be any
>> differences whether or not they're enabled.
>>
> And you're using those via Provider or via CalDAV (just to be sure)? All
> of my read-only calendars are CalDAV. That said, you answered my next
> question in advance, by mentioning that you see no change with them
> disabled.

Sorry, thought I had remembered to include that, that's what I get for
attempting to think on a Monday!

Both of the other calendars are just using ics on the network
(http://www.google.com/calendar/ical/usa__en%40holiday.calendar.google.com/public/basic.ics
) and
(http://ical.wunderground.com/auto/ical/MI/Coopersville.ics?units=english )
Yes, I'm on Win7 x64.

I will install that after I send this email. Want me to give it a shot
without caching on and see if the original problem persists?

-MIchael
Reply all
Reply to author
Forward
0 new messages