Closed
Bug 934201
Opened 12 years ago
Closed 11 years ago
error on start "attention : script doesn't respond ..."
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: andr55, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 (Beta/Release)
Build ID: 20130410210803
Steps to reproduce:
Start Seamonkey
Configured to only start navigator module.
Actual results:
Every time, with a few exceptions noted below, after a delay of about 30 seconds or more, the following displays in a message box :
--
Attention : le script ne répond pas.
Un script sur cette page est peut-être occupé ou ne répond plus. Vous pouvez arrêter le script maintenant ou attendre pour voir si le script se terminera.
Script : chrome://messenger/content/mailTasksOverlay.js:131
[ ]Ne plus demander [Arrêtez le script] [Continue]
--
It translates into english as :
Attention : the script doesn't respond.
A script on this page is maybe occupied or no longer responds. You can stop the script now or wait to see if the script will finish.
Script : chrome://messenger/content/mailTasksOverlay.js:131
[ ]Don't ask any more [Stop the script] [Continue]
--
At this point, only this message box displays.
If I push either of the buttons to the right, almost immediately the navigator window displays. (it is the only module configured to start initially).
This problem has existed for a long time. (Starting some time around when omni.jar first appeared.)
Before it started, I never got these error messages.
(I didn't report it before now since the omni format caused other problems.)
SM is configured to save/load pages from a previous session.
There are 8 email accounts configured, 7 of which access the internet when the email module is started, which is long after this error message appears.
- starting with -safe-mode makes no difference.
- starting with a test profile without pages loaded from a previous session or email accounts defined does NOT produce this error.
- - Additionally installing in the test profile all the extensions that I use does not produce the error either.
- - Additionally defining an email account in the test profile DOES however produce this error.
- Disconnexing the internet wire from the computer causes the error to not appear, without the -safe-mode option, both in my default profile and the test profile than otherwise produced the error.
Expected results:
In all cases tested, SM should have started the navigator module without displaying the error message, after the usual few-second delay.
Which it did when either
1) the internet wire was disconnected, or
2) there were no pages from a previous session to be loaded and no email accounts defined.
Note that the presence or absence of extensions had no effect.
From the error message, I would presume that it is related to the email module, even though no email messages would be downloaded at this stage.
(It must be searching if email messages are available. But why, if I haven't even loaded the module ?)
Comment 1•12 years ago
|
||
SeaMonkey 2.17.1 is old stuff. Please retest with SeaMonkey 2.22 or later: see http://www.seamonkey-project.org
Comment 2•12 years ago
|
||
P.S. A native 64-bit release is available, see under "Contributed builds" at the bottom of the page for "Other Systems and Languages". It was built on Mozilla build infrastructure just like the rest, but it's still considered "unofficial" because of its few users: a chicken-and-egg problem.
Updated•12 years ago
|
Flags: needinfo?(andr55)
Does a new Profile with old Session Restore work correctly?
> 8 email accounts configured, 7 of which access the internet when the email module is started
> Additionally defining an email account in the test profile DOES however produce this error
Is this only a single email account, or did you set up the entire 8?
Anything special, different, peculiar in the email setup you're using?
Any kind of Plugin (virus scanner) that may be interfering?
(In reply to Tony Mechelynck [:tonymec] from comment #1)
> SeaMonkey 2.17.1 is old stuff. Please retest with SeaMonkey 2.22 or later:
> see http://www.seamonkey-project.org
I've downloaded 2.21 (64-bit), but like 2.19 and 2.20, I can no longer modify omni.ja to make it usable (for me), so I haven't tested it on later versions than 2.17.1.
But this problem started not long after omni.jar appeared, and there was no indication of correcting it in change logs.
I'll try it on at least 2.20 when I have a chance.
Flags: needinfo?(andr55)
(In reply to therube from comment #3)
> Does a new Profile with old Session Restore work correctly?
I don't know what you mean by "old Session Restore".
> > 8 email accounts configured, 7 of which access the internet when the email module is started
>
> > Additionally defining an email account in the test profile DOES however produce this error
>
> Is this only a single email account, or did you set up the entire 8?
> Anything special, different, peculiar in the email setup you're using?
I set up more than one account, I forget how many. (I have already deleted the test profile.)
Totally standard pop setups, only changing the default port to that recommended by each email supplier, and authentification (always with password).
It is the same configuration I've had for years, and worked without any significant delay before omni.jar arrived.
(I'm not sure when this problem started, as I had other problems with omni.jar at first. But it was already a problem when omni.jar was renamed to omni.ja.)
> Any kind of Plugin (virus scanner) that may be interfering?
No virus scanners. (I use Linux.)
I just have shockwave flash (which is usually blocked with flashblock), Icedtea-web for java applets (which most pages I load don't use), and Adobe reader (recently added, long after the problem started.)
I filed the bug when I discovered that unpluging the ethernet wire for internet connexion gave no significant delay on startup, on both my usual and test profiles.
I thought that this might give a clue to solving the problem.
I had already discovered that a new profile without email defined or pages reloaded on startup had no significant delay.
And that defining an email account to the new profile caused a long delay, about what happens with my regular profile.
Updated•12 years ago
|
Flags: needinfo?(andr55)
One way or another the problem is solved.
I think it was related to some corruption relating to the plugins, as I disabled by renaming the 3 plugins I had installed : Shockwave Flash player, IcedTea-Web Plugin (for Java applets), and the Macromedia PDF reader.
Initially I still had the problem, and some pages didn't work properly, despite reloading SM.
(IcedTea-Web still showed as installed under help/plugins, so I think that it was disabled, but SM tried unsuccessfully to use it.)
I tried a few other things with no apparent luck, then re-enabled the flash player and Java plugins. (Some pages still didn't work properly.)
(I never display pdf files in the browser, so the pdf plugin, installed long after this problem started, was not re-enabled.)
I tried SM 2.21 (64-bit) in a test profile, and there was no problem, even after adding an email account, and later downloading many emails.
Note that under Linux, plugins for 64-bit applications are installed in a 64-bit library directory, so SM 2.21 (64-bit) saw no plugins installed, unlike the SM 2.17.1 (32-bit) which saw all plugins installed in the 32-bit library directory.
At this point I had not rebooted my machine after disabling/re-enabling the 32-bit plugins.
After rebooting my machine, all pages displayed properly in SM 2.17.1 (32-bit), and the delay in loading had disappeared. :) :) :)
Previously I had tried everything *but* disabling (or uninstalling) and then re-enabling the plugins.
There seems to be nothing else to explain the delay occurring in newly defined profiles with the same 32-bit version of SM (and email accounts defined), but none in the 64-bit version (with email accounts defined).
(BTW, I always disable Java for emails.)
I'll remember to verify the plugins the next time I have a problem.
Sorry for the noise.
Now I just have to find a way to modify a file in omni.ja, that used to be so easy to do ...
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
reopening ...
For some reason, it started right away *once* ... but on subsequent loadings, the long delay problem.
However I have found an additional factor :
With (very fast) wifi, there is no delay.
So it seems to be related either to ethernet, or to the speed of my (relatively slow) adsl connexion.
I tried setting the automatic loading of previous pages to 1 at a time (from the default 3), but it makes no difference. (I didn't think it would, as the pages only start loading after the delay.)
It may be that seamonkey verifies each email account (or the 7 of 8 for which I automatically download on startup), and at least one of the providers is slow to respond.
I have 3 providers : yahoo (2 accounts), google (1), and laposte.net (4).
This delay doesn't seem to have changed since I (in the last few months) changed 2 accounts from google to laposte.net, for other reasons.
Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(andr55)
Resolution: INVALID → ---
I finally found a clue to the cause.
I changed my last gmail account to another provider. (I had discovered that gmail silently deletes supposed spam if user uses pop access, and there is no way around it.)
The delay no longer exists. I've been able to almost instantly start seamonkey several times since.
So it must have had something to do with the interaction between seamonkey and gmail on startup. (And possibly my configuration.)
I have no idea why Seamonkey would be accessing my email accounts and evidently waiting for a response on startup.
So this must be a Seamonkey bug. Any such access on startup should be asynchronous, to avoid such potential problems.
It seems to only be a problem related to gmail accounts, which I no longer use.
So closing.
If a gmail user has the same problem, feel free to reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•