"curr is undefined" in Mac Word 2011

mronkko

When I try to do just about anything with the Word plugin (3.1.2) I get an error message saying "curr is undefined". This started after I tried to insert a reference into a footnote.

I searched the forum and googled, but could not find any other reports of this error.

If it helps, I can send the document for troubleshooting.

Simon

Can you generate a report ID?

mronkko

1183848238

mronkko

Also, with this document the citatins are "out of sync". When I toggle the field codes on, I can see that the citations are in correct places. However, they are not rendered properly.

For example an item with uri
http://zotero.org/groups/6184/items/8ZZ2JQH7

is rendered as
(Wu, 2000)

where as it should be
(Xu, 2005)

mronkko

This problem went away (At least for now) after I restarted Firefox.

mronkko

The problem is back. Now I have a particular document that produces this always when I try to refresh the Zotero fields in the document.

Here is a stacktrace of the error:


zotero(3)(+0000098): 'message' => "curr is undefined"
'fileName' => "chrome://zotero/content/xpcom/citeproc.js"
'lineNumber' => 811
'stack' => "("8","empty",true)@chrome://zotero/content/xpcom/citeproc.js:811
([object Array],", ")@chrome://zotero/content/xpcom/citeproc.js:1006
([object Object],[object Array],[object Object])@chrome://zotero/content/xpcom/citeproc.js:896
([object Object],[object Array],[object Object])@chrome://zotero/content/xpcom/citeproc.js:872
([object Object],[object Array],[object Object])@chrome://zotero/content/xpcom/citeproc.js:872
([object Object],[object Array],[object Object])@chrome://zotero/content/xpcom/citeproc.js:872
([object Object],[object Array],[object Object])@chrome://zotero/content/xpcom/citeproc.js:872
([object Object],[object Array])@chrome://zotero/content/xpcom/citeproc.js:872
((void 0))@chrome://zotero/content/xpcom/citeproc.js:2929
()@chrome://zotero/content/xpcom/citeproc.js:2748
()@chrome://zotero/content/xpcom/integration.js:1657
(true,true)@chrome://zotero/content/xpcom/integration.js:1016
()@chrome://zotero/content/xpcom/integration.js:1143
_callIntegration("MacWord2008","refresh","/Applications/Microsoft Office 2011/Microsoft Word.app/")@chrome://zotero/content/xpcom/integration.js:480
execCommand("MacWord2008","refresh","/Applications/Microsoft Office 2011/Microsoft Word.app/")@chrome://zotero/content/xpcom/integration.js:197
([object XPCWrappedNative_NoHelper])@chrome://zotero/content/xpcom/integration.js:435
"
'name' => "TypeError"

mronkko

Here is another stacktrace. This happens when I try to change the citation style.

zotero(3)(+0000002): 'message' => "curr is undefined"
'fileName' => "chrome://zotero/content/xpcom/citeproc.js"
'lineNumber' => 756
'stack' => "("empty")@chrome://zotero/content/xpcom/citeproc.js:756
([object Object],[object Object],[object Object])@chrome://zotero/content/xpcom/citeproc.js:4586
([object Object],[object Object],[object Object])@chrome://zotero/content/xpcom/citeproc.js:1444
([object Object],[object Object])@chrome://zotero/content/xpcom/citeproc.js:3504
([object Array],(void 0))@chrome://zotero/content/xpcom/citeproc.js:3359
([object Array])@chrome://zotero/content/xpcom/citeproc.js:3270
([object Object],[object Array],[object Array])@chrome://zotero/content/xpcom/citeproc.js:3252
(0,[object Object])@chrome://zotero/content/xpcom/integration.js:1738
()@chrome://zotero/content/xpcom/integration.js:1792
(true,true)@chrome://zotero/content/xpcom/integration.js:978
()@chrome://zotero/content/xpcom/integration.js:1143
()@chrome://zotero/content/xpcom/integration.js:1205
_callIntegration("MacWord2008","setDocPrefs","/Applications/Microsoft Office 2011/Microsoft Word.app/")@chrome://zotero/content/xpcom/integration.js:480
execCommand("MacWord2008","setDocPrefs","/Applications/Microsoft Office 2011/Microsoft Word.app/")@chrome://zotero/content/xpcom/integration.js:197
([object XPCWrappedNative_NoHelper])@chrome://zotero/content/xpcom/integration.js:435
"
'name' => "TypeError"

fbennett

This seems likely to be due to a flaw in the processor, and is likely (but not certainly) triggered by a names formatting operation. If that is correct, I'll need to be able to reproduce the error to track down the source of the problem.

Working with a copy of the document file, try the steps for debugging broken documents. If you get to step 7 with no joy, try to narrow the file down to the smallest portion that will reproduce the error. If you paste a Zotero RDF export of the item data to gist.github.com, save it as a public gist and post the URL from the address bar back here, I'll see if I can reproduce the fault locally.

mronkko

I am currently troubleshooting this myself using the 2.1 branch from SVN and printing things to console. I will most likely find the faulty citation soon and will post the problematic reference online when I find it.

mronkko

The problematic item is now exported to

http://dl.dropbox.com/u/694399/ExportedItems.rdf

mronkko

If I remove the edition-field, it seems to work. Also, If I change the citation style, it seems to work.

So this only seems to happen with the MISQ style that I have written myself. The CSL file is available at http://www.zotero.org/styles/misq/dev

fbennett

There is an empty group in the style at line 246, which fails validation. I'm not sure if it was the cause of the error, but it should be eliminated just to be safe.

fbennett

At least with a valid copy of the style (one from which the empty group has been removed), the sample reference seems to work fine here under OpenOffice. Try removing the empty group from your copy of the style locally, reinstalling the style, restarting Firefox, and then see if the original document will process successfully.

mronkko

Seems to work now. The style in http://www.zotero.org/styles/misq/dev works fine. It was my old copy that had a problem.

fbennett

Yay, that's great news.

mronkko

Yep. Still, a more informative error message than "curr is undefined" would be nice when the actual problem is an error in the csl style.

fbennett

Point taken. The processor itself assumes valid CSL, and unexpected things may happen (including bad formatting without issuing an error) when the style code is invalid. We try to encourage the validation of custom styles, but it depends on people coming across that documentation. Is there a spot where a prominent message and a pointer would have helped?

mronkko

In my case, an error message that tells that the CSL processor encountered an error would have helped. Since I knew that this was a style that I had written my self, I would have probably concluded more quickly that this was the cause of the error. Now I started to figure it out by checking out an SVN copy of Zotero and running firefox from terminal to get the javascript stack trace.

If an error message is implemented, it could provide two suggestions for the user
1) To change the CSL style and to see if the error persists
2) Include a link to the validation guidelines

In my case this would have saved an hour or two of time.

fbennett

One possibility for the future might be to do a checksum of the CSL, and issue a popup with details about validation if it is identified as code not drawn directly from the CSL repository.

adamsmith

How hard would it be to have Zotero validate csl before installing? - I think it should just be a worning because their might be some cases where people actually do want to install an invalid style but something like "The style "Mronkkos House Journal" is not valid csl and may not work properly with Zotero. Are you sure you want to install it OK --- Cancel" would be great...

mronkko

In this case validation during install might not have helped, because I had edited the style after installing.

adamsmith

uh - but editing the styles directly in the style directory? That seems a little reckless... I'd guess you're maybe one of two people doing that - it's certainly not mentioned even as a possibility in the documentation.
If we can get a better error message - great - but my understanding is that it's actually not trivial to get citeproc to always fail nicely and consistently (and in many cases it doesn't even fully fail, it just doesn't create the correct output). So validation on install would seem to provide a safeguard for most cases - and if you want to hack your style right inside Zotero, you should really just get a validating editor.

fbennett

Validation could be run when a style is selected (i.e. just before it is instantiated to run by Zotero), which would catch all cases. I like the idea of a warning + user override; blocking the install completely would be troublesome in some situations.

mronkko

Actually, now that I think about it, I did edit the style in another directory and then installed it. So a validating installer would have prevented this problem.

Also, in my case the problem was not that the citeprocs.js would have produced incorrect output, but it failed with an error message that "broke" Zotero for this particular document.

Simon

The other problem is actually performing validation. I've been meaning to look into this validator for a while now, but I have no idea if/how well it works.