Error refreshing Vancouver. Rapport ID 1919864613

Hello ! Using macOS 10.13.6 and LibreOffice 6.2.4.2.

On my actual paper : adding citation works. Adding or refreshing my Vancouver style bibliography shows error while updating. Copying the document, or the text in a new one, deleting the bibliography and adding a new one doesn't work. Changing style by setting document preferences works and updates correctly, but going back on Vancouver after doesn't.

On a new paper : Vancouver works !

What's wrong ?

Chloe
  • [JavaScript Error: "3 is read-only" {file: "chrome://zotero/content/xpcom/citeproc.js" line: 19974}]
    @fbennett, @adomasven: Another report of this. The relevant line is here, though that line hasn't changed in many years, so the problem clearly is elsewhere. Since these were both in LO, it seems like this may be related to the recent LO plugin changes.
  • @cplczr: If possible, you should run through the last step of Debugging Broken Documents, isolate the broken section, and send it to us.
  • I tried the half by half technique, and it's working in none of them ...
  • Now that you've mentionned it, I think I accepted Zotero updates or something this morning
  • That just means you have to cut down one of the halves more.
  • I don't get it, it's not working in half A, not working in half B
    I get the idea to search for the broken section if it's working in one half, but none ??
  • Just pick one of the halves at random and continue from there. The goal here is to find the smallest possible section where the problem still occurs, so that you don't have to send us your entire document.
  • Found it !
  • Great. Would you mind emailing it to support@zotero.org with a link to this thread so that we can try to fix the underlying problem?
  • I just emailed it, thank you !
  • Thanks, I can reproduce the problem in the excerpt you sent. We'll work on a fix.

    In the meantime, simply reinserting the citation in the original document might be sufficient to fix this in your document. (If it happens reliably when you reinsert the same items, let us know.)
  • I reinserted the citations and the same error message just showed up like earlier
  • edited July 16, 2019
    OK, @fbennett, this broke with the update from 1.2.12 to 1.2.13. I'll send you the excerpt.
  • edited July 16, 2019
    Okay, it's throwing the same error as reported here. In this case it's triggered by an attempt to apply page-range-format="minimal" to a page field value of "22-22". That's logically impossible, and it was crashing the processor.

    I don't know how Zotero behaves with this input, but the processor bug is of long standing. The code that does numeric range collapsing hasn't changed significantly in over a year, and I get the same error in the test suite with versions as far back as I can run them.

    I've added the item that triggers the error to a Vancouver collection in the Jurism Test Items library for reference in CSL development.

    The bug is fixed in citeproc-js 1.2.17, which just went up.
  • Great — thanks for the quick fix. I've pushed out a Zotero beta version with this fix, so @cplczr, for the moment you can install that over your current version and switch back to Zotero 5.0.71 when it comes out in the next couple days.
    I don't know how Zotero behaves with this input, but the processor bug is of long standing. The code that does numeric range collapsing hasn't changed significantly in over a year, and I get the same error in the test suite with versions as far back as I can run them.
    This definitely started occurring between citeproc-js 1.2.12 and 1.2.13, with no accompanying changes in Zotero. Maybe there was some input other than what you tested that also triggered it? In any case, 1.2.17 fixes the problem in this document, so we're hopefully good.
  • Fingers crossed. If there are further problems I'll get on it.
  • @dstillman: Found the change that caused this. There is a 'use strict' declaration at the top of the source from version 1.2.13. Without it, the code that triggered the bug (an array assignment into a string) fails silently. In strict mode, we get a read-only error. The test framework runs in strict mode, which explains the difference in our outcomes.

    Open to advice on what to do about that declaration. Should it be removed?
  • No need to remove it — we're unlikely catch bugs otherwise if there aren't already tests for them.
Sign In or Register to comment.