Zotero FF fails to download an item and then crashes Error 1496844994

csteer1

I have tried three times now to use the Zotero icon in the address bar to import the information from this webpage:
http://www.icrc.org/eng/resources/documents/publication/pcustom.htm

When I do, a pop-up box appears in the Zotero frame saying it is saving the information, but only shows an X next to "snapshot". If I subsequently try to add the item manually, then it says an error has occurred and that I have to re-start Firefox.

All I can think is that the pdf which it would normally automatically download as an attachment (per my preferences) is more than 600 pages long, and maybe it's too big. But even when I change the preference so that it doesn't automatically attach the pdf, it still does the same thing. Help please?

adamsmith

I can replicate that. Something weird going on on that page:

[JavaScript Error: "[Exception... "Component returned failure code: 0x80630003 (NS_ERROR_STORAGE_CONSTRAINT) [mozIStorageStatement.execute]" nsresult: "0x80630003 (NS_ERROR_STORAGE_CONSTRAINT)" location: "JS frame :: chrome://zotero/content/xpcom/db.js :: Zotero.DBConnection.prototype.query :: line 145" data: no] [QUERY: INSERT OR IGNORE INTO collectionItems VALUES (?,?,?)] [ERROR: insert on table "collectionItems" violates foreign key constraint "fki_collectionItems_itemID_items_itemID"]"]

Dan will need to look at that.

csteer1

Thank you, for such a quick reply, I await expert response!

dstillman

In the library root there's a clearer error:

[Exception... "Component returned failure code: 0x80630003 (NS_ERROR_STORAGE_CONSTRAINT) [mozIStorageStatement.execute]" nsresult: "0x80630003 (NS_ERROR_STORAGE_CONSTRAINT)" location: "JS frame :: chrome://zotero/content/xpcom/db.js :: Zotero.DBConnection.prototype.query :: line 145" data: no] [QUERY: INSERT INTO itemAttachments (itemID, sourceItemID, linkMode, mimeType, charsetID, path, syncState) VALUES (?,?,?,?,?,?,?)] [ERROR: parent is not a regular item]

The translator is creating a note item and then trying to add a child attachment to it.

adamsmith

@Dan - thanks. So I think the problem is that the sanity check for item type fails because ZU.itemTypeExists(1) returns true.
(function is here:)
https://github.com/zotero/zotero/blob/master/chrome/content/zotero/xpcom/utilities.js#L960

I haven't been able to figure out what's going on exactly beyond that.

aurimas

I think ZU.itemTypeExists(1) is functioning as intended here. We should have just been more careful about what we pass to it from the RDF translator. I added a check to make sure we don't consider integers.

dstillman

Yeah, that sounds right. The page gives DC.type = 1, and we're checking that value thinking that it might be a Zotero item type name, but itemTypeExists() will return true for valid itemTypeIDs as well. The fix, then, would be to only call itemTypeExists() if parseInt(type) == type. I'm not actually sure why we're doing this to begin with, since our types aren't really based on DCMI Metadata Terms, but I guess it allows us to avoid including a few of the types ("date") in the switch statement below...

aurimas

Seems that Chrome (on its own, without connecting to ZSA) is not picking up the updated RDF translator. Can someone confirm that it's not just something odd on my end?

I am seeing zotero.org responding with the update, but it doesn't look like Chrome is downloading it.

dstillman

Just saved fine for me in Chrome to server, though it wasn't cached before the change. Does it work if you restart Chrome?

aurimas

Restarting didn't help, but it worked after I cleared the cache. In the logs I saw that there was a newer version of RDF (than the one returned from zotero.org) already in the cache. Not entirely sure how that happened, but it's probably specific to my dev environment and unlikely to be a problem for end users.