unresponsive script problem

stephengourlay

Since upgrading to 2.0 I get an unresponsive script error message. Initially this happened on re-starting FFox (3.6). That has stopped, but when I try to sync I get the error message again. Two scripts have been referenced: Script: chrome://zotero/content/xpcom/db.js:313 and Script: chrome://zotero/content/xpcom/debug.js:47.

I tried resetting my Translators & Styles - no effect (except the second error message appeared). Resetting also had the effect of restoring the Report Errors option - that's now greyed out again.

Any suggestions? I've tried searching, but the only other info I could find concerned old versions of Zotero. I'm using Windows XP.

(I did not experience FFox freezing but after running sync overnight and found it was still going 8-9 hours later I gave up).
Thanks.

stephengourlay

I notice that different scripts are involved - just now Script: chrome://zotero/content/xpcom/data/item.js:4557

Should I Stop the script, or click on Continue? As I have no idea what the implications of either option are I'm a little in the dark.

dstillman

http://www.zotero.org/support/kb/unresponsive_script_warning

stephengourlay

Thanks Dan - I'll try that. (I'm trying a first sync - but I have a large database so I guess it'll take a long time).

lbonura

I, too, have been getting an unresponsive script error:

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: chrome://zotero/content/xpcom/db.js:147

Are you going to fix this issue or must we disable it manually as you suggested?

Bionatsci

Are you going to fix this issue or must we disable it manually as you suggested?

Dan has said that they are working on speed improvements which should make this less of an issue. However, IMO, this is less of a Zotero problem and more Firefox being a bit overzealous with it's time limits in declaring a script unresponsive on slower/more heavily used machines.

Also there will always be circumstances in which a complex script runs slower than expected and triggers a timeout if one is set, however efficient it is. This could be slow hardware, heavy processor usage from other programs, or a particularly large import / Zotero library. It's then up to the user to decide the balance they want to strike between false positives and waiting a long time when a script does actually become unresponsive.