Routing paper tabs to Zotero in bulk: a working Connector patch, and a question about /connector/detect

[Michael Simon]

I've been building Tabglutton, an MIT-licensed tab-management extension for Firefox-based and Chromium based browsers. It clips a pile of open tabs into a notes app in one go. A good chunk of my own backlog is papers, and I'd prefer an option to route them into zotero. So I'd like to route them there instead.

The part I can't do well on my own is deciding which tabs are papers. I can guess from the URL, but that means maintaining a hostname list for arXiv, OpenReview, PubMed, bioRxiv, publisher and journal domains, proxies, and PDF URLs. I'd much rather ask Zotero.

So I built a proof of concept: a patch against zotero-connectors commit 48ad1fe0 adding two requests over runtime.onMessageExternal.

  { "action": "getTabInfo", "version": 1, "tabId": 123 }
  { "action": "saveTab",    "version": 1, "tabId": 123 }

  https://github.com/mlsimon734/tabglutton/blob/main/poc/zotero-connector.patch
  https://github.com/mlsimon734/tabglutton/blob/main/docs/ZOTERO_POC.md

It works. On Chrome 151, with both extensions unpacked, getTabInfo classified arxiv.org/abs/1706.03762 as { itemType: "preprint", label: "arXiv.org" }, and the full route saved it to Zotero and closed the tab. Firefox builds fine but I've only smoke tested it by hand. The patch lives outside my build, so no AGPL source ends up in the MIT extension.

getTabInfo is the piece I didn't anticipate when I first thought about this. A generic saveTab triggers the toolbar action but can't tell me which tabs are worth sending, so on its own it leaves me with the hostname list anyway. Exposing the translator result you've already computed solves it, and the routing policy stays on my side.

Since then I've been reading server_connector.js and I suspect I may not need the Connector for that half at all — POST /connector/detect takes uri, html and cookie, runs detection, and returns serialized translators, and itemType is in TRANSLATOR_PASSING_PROPERTIES. Am I reading that right, and is calling it from a third-party extension something you'd consider supported? If so, the only thing I really need from the Connector is the save, since saveItems wants items that are already translated and the translation has to happen in the browser with the user's session and institutional access.

I did look for earlier discussion first. zotero-connectors #60 is the closest — adomasven said this would be runtime.onMessageExternal and that a PR could be accepted (https://github.com/zotero/zotero-connectors/issues/60#issuecomment-435852764), but that issue was really about keyboard shortcuts and got closed over an unrelated Google Docs conflict, so the question never got answered. There's also https://groups.google.com/g/zotero-dev/c/9mLkaLjkBps from last year, which got no replies.

On authorization: my POC takes calls from any extension with a sender.id and rejects web pages, which is fine for an experiment and obviously not for real. An allowlist, a first-use prompt, a known-IDs list — I don't have a preference and I'd implement whatever you think is right.

Mainly I want to know if this is a direction you'd take a PR in. If it isn't, that's a useful answer too and I'll build around it.

(I asked on the forums first and dstillman pointed me here: https://forums.zotero.org/discussion/133142/allow-other-browser-extensions-to-invoke-zotero-connectors-save-action)