Don't alter the Function prototype -- bad things happen. about zotero-better-bibtex HOT 14 CLOSED

Do you have an example of what you're trying to import?

from zotero-better-bibtex.

Here's one of the files I've tried to import:

https://dl.dropboxusercontent.com/u/1111886/Elementy%20eksportowane.rdf

It's in Zotero RDF format. But the problem appears also with other formats and other set of items. I've tried several times with different combinations and always I'm getting an empty collection with no items imported.

from zotero-better-bibtex.

The BBT detection was too greedy (apologies for the disruption, genuinely appreciate the heads-up -- I depend on reports to fix my mistakes), that has now been fixed. But the sample file doesn't import either with the fixed BBT in place or with BBT disabled. so there is something additional going on.

from zotero-better-bibtex.

I believe it's better to move discussion form Zotero Forum here. I've deleted my post on Zotero Forum and pasting it here:

After removing BBT and resetting translators, the file (Zotero RDF) imports properly; without translators reset it fails with the following error:

[JavaScript Error: "Zotero.RDF: getResourceURI called on invalid resource" {file: "chrome://zotero/content/xpcom/translation/translate.js" line: 2648}]

Other formats, as RIS or EndNote XML imports properly with new version of BBT.

from zotero-better-bibtex.

I see that error now too (thanks for the great analysis), but I truly don't understand through what mechanism BBT could be causing this. The translators run in a sandbox which is supposed to render them unable to cause side-effects, and this error occurs after BBT has decided it won't handle the import.

from zotero-better-bibtex.

There seems to be an ordering issue in Zotero. I've released a new version that puts itself behind the RDF detection, but damned if I know why this helps; I hope Dan can weigh in on why this does seem to help.

from zotero-better-bibtex.

I don't know any programming nuances of Zotero, but in newest version of BBT import works :) Thank you!

from zotero-better-bibtex.

Well thank you for sticking it out, and for the great analysis.

from zotero-better-bibtex.

BBT is a very useful extension, so it's pleasure to help.

from zotero-better-bibtex.

I hope Dan can weigh in on why this does seem to help.

This one isn't really my department. @simonster or @aurimasv might have an idea.

from zotero-better-bibtex.

In your translators you define Array.prototype.where = function(f) {... which becomes an enumerable property of Array. Because of the way translators are loaded and unloaded from the sandbox (don't have a reference right now, but I'll find one if you want...), the global environment in the sandbox is not cleared for each translator, so changing globals like this affects all translators that follow (though interestingly the error pops up only for doImport, which would be after Better Bibtex goes through detectImport even with priority: 199. I'll have to look into the details there).

Anyway, in RDF, we do something we shouldn't - we're iterating an array using for each(... in ..) { - which causes us to pick up where as an RDF resource and, in turn, throw an error.

You could solve this from your end by defining where as a non-enumerable property of Array instead. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty and http://stackoverflow.com/a/22980493/543005

I recall talking to @simonster about clearing the sandbox for each translator (I was trying to use some globals that were being overwritten between detectWeb and doWeb), but we never arrived at a proper solution. I'll fix RDF to iterate arrays properly in the mean time.

from zotero-better-bibtex.

though interestingly the error pops up only for doImport, which would be after Better Bibtex goes through detectImport even with priority: 199. I'll have to look into the details there

I'm still not certain about this, but here's my guess. RDF store object for the RDF translator is created as a global during detectImport. At this point, an XPConnect wrapper is initialized for the object using the current sandbox environment (with Better BibTeX with priority 199, it would use the unmodified Array.prototype). During doImport, when we request getArcsOut and receive an array as a result, the XPConnect wrapper uses the sandboxed Array object from when it was initialized to sanitize getArcsOut return.

Maybe @simonster has a better theory.

Edit: I'll just note here that this seems to stem somewhere from https://bugzilla.mozilla.org/show_bug.cgi?id=760109 and this comment appears to be about a similar issue.

from zotero-better-bibtex.

Ah! Super thanks for the analysis, I'll make sure that is taken out; I'll
inherit from array rather than changing it's prototype.

from zotero-better-bibtex.

A new version of BBT is out that doesn't mess with Array.prototype

On Mon, May 19, 2014 at 3:57 PM, Emiliano Heyns <
[email protected]> wrote:

Ah! Super thanks for the analysis, I'll make sure that is taken out; I'll
inherit from array rather than changing it's prototype.

from zotero-better-bibtex.