Update Zotero.QuickCopy.getContentFromItems() for new citation API

[dstillman]

QuickCopy dragging is currently broken due to the changed citation API (and even a try...catch doesn't catch anything, oddly).

The citation calls at the bottom need to be updated.

[fbennett]

The attached patch quick-copy-fix.patch should get things working again. In the patch I've changed the comment to reflect the default hotkey in the current implementation.

[fbennett]

(Oops. Initial version of the patch had mistakes in the processor API. Have overwritten it with a corrected copy.)

[dstillman]

(In [6235]) Closes #1691, Update Zotero.QuickCopy.getContentFromItems() for new citation API

Thanks to Frank for the patch

[dstillman]

Actually this is still broken for me. Just to be clear, this is dragging—not related to Ctrl-Alt-A.

With Shift depressed, I'm getting this:

Error: TypeError: this.session is undefined with format 'bibliography=​http://www.zotero.org/styles/chicago-author-date'
Source file: chrome://zotero/content/xpcom/itemTreeView.js
Line: 1782

Without Shift, the drag is just breaking silently.

[fbennett]

Whups, sorry for the misstep. New attachment quick-copy-fix2.patch may be a little closer to the mark.

[fbennett]

The bibliography output was incorrect with Chicago author-date (was getting the author substitute string instead of the author). The two runs of the processor were interacting with one another -- a carryover variable was not being reset. I've fixed that now, in the version 1.0.41 release of the processor.

[dstillman]

Is dragging (with or without Shift) actually working for you?

I'm still getting intermittent processor errors (e.g., Error: TypeError: state.tmp.date_object is undefined with format 'bibliography=​http://www.zotero.org/styles/chicago-author-date'
Source file: chrome://zotero/content/xpcom/itemTreeView.js
Line: 1776), but even when I don't dragging in bibliography mode still just isn't working for me, whereas it works fine in export mode. The content is actually making it out of the processor and back to the drag-and-drop handling code in itemTreeView.js::onDragStart(), but something is still killing the drag for me.

[fbennett]

Works without a hitch under Linux (jaunty), Firefox 3.6.x (3.6.7 as of a couple of minutes ago), both with and without shift. Just to be sure, I explicitly installed Chicago author-date from ​http://www.zotero.org/styles/chicago-author-date, and tried with both gedit (plain text drop) and OO (rtf drop). In OO, the result comes through with literal HTML markup, but that may be expected breakage in OO 3.0 -- in any case the content is coming through okay.

From the date error, it looks like the processor is stumbling over a date. Looking at the code lines that handle the initial composition of dates for internal use by the processor, it seems possible that there could be edge cases that would trip it up. If you post a date string from an item that produces one error (or both, if it's erratic), I may be able to reproduce the behavior here -- and in any case it may show up some possibilities that I've overlooked.

[fbennett]

I've been able to produce something like this by putting a non-parseable date string in the date field ("Sometime in the past"). Zotero currently passes this through on the date object as a "part" element on the "literal" key:

{
  "literal": {
    "part": "Sometime in the past"
  }
}

The literal value should be passed as a simple string instead:

{
  "literal": "Sometime in the past"
}

Don't know how much of what you're seeing this explains, but it's at least something to fix. I have a version of the processor running here that patches up the literal value, but I'll hold it back from release unless you'd like to have it up. With the value corrected, the literal date does come through -- in too locations, in Chicago author-date, but that's the processor's fault, and will be fixed in due course.

[fbennett]

I've gone ahead and included a workaround for the literal date format, in processor version 1.0.43. When the input format is fixed up, I can pull out the extra code.

The same release also includes a declaration of the CSL error reporting function, which was previously missing, and apparently caused the processor to crash completely when it was encountered, which might also have been contributing to intermittent failures.

[simon]

(In [6243]) references #1691, Update Zotero.QuickCopy.getContentFromItems() for new citation API
put a string in date.literal, instead of the whole date object, when passing to citeproc-js

[dstillman]

(In [6251]) Addresses #1691, Update Zotero.QuickCopy.getContentFromItems() for new citation API

Frank's latest patch, but drag-and-drop is still broken for me on OS X. Need to see if this is just my working copy.

[simon]

(In [6252]) closes #1691, Update Zotero.QuickCopy.getContentFromItems() for new citation API
caches updateCSL.xsl, since apparently doing an XHR to load it during drags was breaking things

[simon]

(In [6253]) addresses #1691, Update Zotero.QuickCopy.getContentFromItems() for new citation API
fix up problems on first drag