Add "Save Link to Zotero" context menu

[dstillman]

In Firefox this option ("Save Link as Zotero Item") saved either a webpage item or a top-level file (e.g., PDF). For the former, it'd be nice to do automatic translation falling back to webpage (like we do for feed items). The latter is more important, since it'd be a replacement for the Firefox save-dialog modification for people not viewing PDFs in the browser.

[adomasven]

We might want to restrict where we show other context-menu options for the connectors, and only show this option on link right-clicks. That way the option will not be hidden in a Zotero Connector submenu. BrowserExt: https://developer.chrome.com/extensions/contextMenus#type-ContextType Safari: https://developer.apple.com/library/content/documentation/Tools/Conceptual/SafariExtensionGuide/AddingContextualMenuItems/AddingContextualMenuItems.html

[adomasven]

What is the expected behaviour for pages where the primary translator returns "multiple" and we would show an item selection window?

Possible options are:

1. Show a select window and proceed with the save
2. Show a progress window message saying that the link needs to be opened to be translated

My vote goes for 2, just because 1 might be too unexpected.

[adomasven]

Okay, so after playing around with this a bit more I found out that we are very limited by CSP here. The "hiddenBrowser" feature for Zotero.HTTP.processDocument is implemented as an iframe on the injected page and content outside of the current domain is loaded via XHR and then manually written into the iframe.

The main implication is that document.location.href attribute will be set to the parent page. I.e. if you do 'Save Link to Zotero' on scholar.google.com and the resource is at jstor.com, the document.location.href attribute will be the scholar.google.com one. At the moment there are 224 mentions of document.location.href in various translators, mostly to add a snapshot attachment. Thus items saved in such way fetch wrong snapshots.

We could still offer this for same-origin links or only offer the feature when Zotero is running and do the translation within Zotero.

[zuphilip]

We could also try to get rid of most document.location.href in translator codes, because they are normally not needed and one can substitute this with the url parameter of the detectWeb and doWeb functions. Would this be helpful?

[adomasven]

I think translators should be able to rely on all properties of document being correct as it is the only interface used in translation to access the page contents. We should figure this out within Zotero.

[adomasven]

Also relevant issues here: zotero/zotero#348 and #10. Simon had an idea for switching processDocuments to XHR on Zotero, although with XPCOM you could probably work around the incorrect document.location property. Not sure if he had any better ideas for implementing it for the connectors.

[simonster]

You could give the translator an ES2015 proxy that overrides document.location with an object with the proper functionality and passes other property accesses through, since that's now supported in current versions of all major browsers. That's basically what we were doing here. OTOH, it would be a lot simpler just to make translators not rely on that property.

[adomasven]

The cross-origin load issues should not be an issue after ff49648

[dstillman]

Thread: https://forums.zotero.org/discussion/19707/saving-links-to-zotero-standalone

[dstillman]

Requested for non-PDF files too: https://forums.zotero.org/discussion/69534/right-click-link-to-file-save-to-zotero

Not sure how well we can do this with content-type monitoring. Using the downloads API might be another option.