I have tried debugging with no results and no further guidance thus far
from the group here. As there was an calendar event yesterday this
became even more annoying as the sign-on requests became even more
frequent and it was impossible to dismiss the pop-up as each attempt
resulted in yet another sign-on request.

I have for the moment removed the addon.

Given the problem must be somewhere in my profile I am considering a
full clean restart of the calendar system after which I will reinstall
the addon.

Can I simply shut SeaMonkey down, remove the calendar-data directory and
its contents and all the calendar user_perf entries from the prefs.js
before restarting to reinitialize it?

If not, I have SeaMonkey on another machine where I am not using the
calendar. Could I simply copy its calendar-data directory and replace
my current calendar user_pref entries with those from that prefs.js file?

I hope that once the calendar system is restarted cleanly that I will be
able to reinstall the addon and have it work again.

Other suggestions welcome.

Dave

David H Durgee wrote:
> I have tried debugging with no results and no further guidance thus far
> from the group here.  As there was an calendar event yesterday this
> became even more annoying as the sign-on requests became even more
> frequent and it was impossible to dismiss the pop-up as each attempt
> resulted in yet another sign-on request.
>
> I have for the moment removed the addon.
>
> Given the problem must be somewhere in my profile I am considering a
> full clean restart of the calendar system after which I will reinstall
> the addon.
>
> Can I simply shut SeaMonkey down, remove the calendar-data directory and
> its contents and all the calendar user_perf entries from the prefs.js
> before restarting to reinitialize it?
>
> If not, I have SeaMonkey on another machine where I am not using the
> calendar.  Could I simply copy its calendar-data directory and replace
> my current calendar user_pref entries with those from that prefs.js file?
>
> I hope that once the calendar system is restarted cleanly that I will be
> able to reinstall the addon and have it work again.
>
> Other suggestions welcome.
>
> Dave

I've never used the Google Calendar provider so hadn't replied before
(though I used to use another plugin to sync GMail contacts, but that
was several years ago and I no longer even have a Google account), but a
few thoughts that may or may not help...

I don't remember whether you've already mentioned clearing cookies, but
that might help. Also may be worth removing any Google or GMail related
entries from the password manager, in case for some reason an existing
entry isn't being updated correctly (but make sure you know what the
passwords are, for when you need to re-enter them!)

ABE is a feature of NoScript which restricts sites from running scripts
hosted on other sites, even if both sites are whitelisted to run
scripts. If that's blocking something, it needs more than just
temporarily allowing scripts for those sites - you also need to
configure ABE rules to allow the interaction between the two. For
testing purposes, it's probably easiest to completely disable NoScript,
restart SeaMonkey, and then try logging in for the calendar provider.
Of course, you'll want to re-enable NoScript before any other browsing
(I'm only suggesting this for testing the provider), but if the calendar
provider works without NoScript, it at least narrows the problem down to
configuring NoScript appropriately.

You mentioned editing logins.json manually, but I'm not sure that would
work anyway. At least when a master password is set, the entries are
encrypted using a key stored in key4.db. I think I saw somewhere that
the entries are still encrypted even if not using a "master password",
and the difference is just whether or not the key in key4.db is itself
encrypted (using a key derived from the master password).

Before wiping out the calendar data in your current profile in the hope
it might then work, you could create a new blank profile and try setting
up the calendar provider there. Go to Tools > Switch Profile > Manage
Profiles to create a new profile, and then you can switch between the
two as needed.

If that doesn't work, it seems likely something has become broken with
an update and mucking around with the profile is unlikely to help (e.g.
either a SeaMonkey update or something Google have changed might require
corresponding changes to the plugin to keep it working).

If it does work with a new profile, it's then a case of working out what
in your current profile is causing the problem. Rather than wiping out
bits of your current profile in the hope of finding a fix, it may be
safer to go the other way - with SeaMonkey closed, copy parts of your
existing profile into the new one, and see whether the provider still
works before closing and copying across something else. If/when it
stops working, you've just copied across the bit that causes the
problem. I think you've already mentioned the main things I'd suspect:
* I'd probably start with copying logins.json, key4.db and cert9.db; I
think those all have to go together, since a key stored in key4.db
encrypts parts of the others. If it works after copying those, it may
be worth re-copying logins.json each time you change something else, in
case the problem doesn't occur anyway if there's already a valid
password / token saved.
* prefs.js entries related to the calendar provider.
* prefs.js entries related to the calendar in general
* Maybe the calendar data itself, though it seems less likely to me.

As I said, I've never used the Google Calendar provider so can't be much
help with specifics, but perhaps something above might be of some use
(or prompt other ideas)...

--
Mark.

Mark Bourne wrote:
> David H Durgee wrote:
>> I have tried debugging with no results and no further guidance thus
>> far from the group here.  As there was an calendar event yesterday
>> this became even more annoying as the sign-on requests became even
>> more frequent and it was impossible to dismiss the pop-up as each
>> attempt resulted in yet another sign-on request.
>>
>> I have for the moment removed the addon.
>>
>> Given the problem must be somewhere in my profile I am considering a
>> full clean restart of the calendar system after which I will reinstall
>> the addon.
>>
>> Can I simply shut SeaMonkey down, remove the calendar-data directory
>> and its contents and all the calendar user_perf entries from the
>> prefs.js before restarting to reinitialize it?
>>
>> If not, I have SeaMonkey on another machine where I am not using the
>> calendar.  Could I simply copy its calendar-data directory and replace
>> my current calendar user_pref entries with those from that prefs.js file?
>>
>> I hope that once the calendar system is restarted cleanly that I will
>> be able to reinstall the addon and have it work again.
>>
>> Other suggestions welcome.
>>
>> Dave
>
> I've never used the Google Calendar provider so hadn't replied before
> (though I used to use another plugin to sync GMail contacts, but that
> was several years ago and I no longer even have a Google account), but a
> few thoughts that may or may not help...
>
> I don't remember whether you've already mentioned clearing cookies, but
> that might help.  Also may be worth removing any Google or GMail related
> entries from the password manager, in case for some reason an existing
> entry isn't being updated correctly (but make sure you know what the
> passwords are, for when you need to re-enter them!)
>
> ABE is a feature of NoScript which restricts sites from running scripts
> hosted on other sites, even if both sites are whitelisted to run
> scripts.  If that's blocking something, it needs more than just
> temporarily allowing scripts for those sites - you also need to
> configure ABE rules to allow the interaction between the two.  For
> testing purposes, it's probably easiest to completely disable NoScript,
> restart SeaMonkey, and then try logging in for the calendar provider. Of
> course, you'll want to re-enable NoScript before any other browsing (I'm
> only suggesting this for testing the provider), but if the calendar
> provider works without NoScript, it at least narrows the problem down to
> configuring NoScript appropriately.
>
> You mentioned editing logins.json manually, but I'm not sure that would
> work anyway.  At least when a master password is set, the entries are
> encrypted using a key stored in key4.db.  I think I saw somewhere that
> the entries are still encrypted even if not using a "master password",
> and the difference is just whether or not the key in key4.db is itself
> encrypted (using a key derived from the master password).
>
> Before wiping out the calendar data in your current profile in the hope
> it might then work, you could create a new blank profile and try setting
> up the calendar provider there.  Go to Tools > Switch Profile > Manage
> Profiles to create a new profile, and then you can switch between the
> two as needed.
>
> If that doesn't work, it seems likely something has become broken with
> an update and mucking around with the profile is unlikely to help (e.g.
> either a SeaMonkey update or something Google have changed might require
> corresponding changes to the plugin to keep it working).
>
> If it does work with a new profile, it's then a case of working out what
> in your current profile is causing the problem.  Rather than wiping out
> bits of your current profile in the hope of finding a fix, it may be
> safer to go the other way - with SeaMonkey closed, copy parts of your
> existing profile into the new one, and see whether the provider still
> works before closing and copying across something else.  If/when it
> stops working, you've just copied across the bit that causes the
> problem.  I think you've already mentioned the main things I'd suspect:
> * I'd probably start with copying logins.json, key4.db and cert9.db; I
> think those all have to go together, since a key stored in key4.db
> encrypts parts of the others.  If it works after copying those, it may
> be worth re-copying logins.json each time you change something else, in
> case the problem doesn't occur anyway if there's already a valid
> password / token saved.
> * prefs.js entries related to the calendar provider.
> * prefs.js entries related to the calendar in general
> * Maybe the calendar data itself, though it seems less likely to me.
>
> As I said, I've never used the Google Calendar provider so can't be much
> help with specifics, but perhaps something above might be of some use
> (or prompt other ideas)...
>

Your idea sounded good, so I gave it a try on another computer. I
created a new profile and after that installed the addon. Unfortunately
I must have missed a prerequisite of some sort, as when I open the
calendar or the today pane I don't get any sort of a login prompt.
Hitting the synchronize button on the calendar does nothing.

Perhaps someone else has an idea what I missed.

Dave