It seems that the issue wasn't that zotero:// URLs can't be loaded in a content
browser, but rather that the report extension was returning a channel that the
content browser couldn't access. For some reason, it handled that failure by
passing the URL off to the OS, which then opened a duplicate instance of Zotero.
Also:
- Remove ensureBrowserType() and always use <browser type="content"> in
basicViewer (see b8966f)
- Fix system principal being used to load extensions without `loadAsChrome` set
to true if an extension with `loadAsChrome` set to true had been loaded in the
past
- The protocol can no longer be marked "dangerous to load," only "UI resource"
(accessible inside browsers but not by web pages).
- The protocol needs to run in the main process.
- We need to replace the XUL browser to reset its type attribute depending on
whether we're loading a zotero protocol URI - zotero protocol URIs, maybe due
to the protocol handler's tight coupling with the main process, cannot load in
type="content" browsers.
zotero://open-pdf/library/items/AABBCCDD?annotation=[annotation-key]
Fallback to a page if annotation is missing:
zotero://open-pdf/library/items/AABBCCDD?page=123&annotation=[annotation-key]
Fixes#2125
And use when opening PDFs in My Library from items list and
zotero://open-pdf
This also adds "Zotero" to the main PDF reader pref, which will be the
real way to set this, but that option is hidden for now so that group
library items will still open with the configured reader.
- Support items within collections and searches:
zotero://select/library/collections/:collectionKey/items/:itemKey
zotero://select/groups/:groupID/collections/:collectionKey/items/:itemKey
- Fix the 'itemKey' parameter:
zotero://select/library/collections/:collectionKey/items?itemKey=:itemKey1,:itemKey2
- Select library root if collection/search not specified
This adds selectItems() to ZoteroPane and collectionTreeView and removes
the ancient, unused 'expand' argument to selectItem(), which didn't
really make sense there. It also includes a new
itemTreeView::ensureRowsAreVisible() that tries to scroll to an
appropriate place (or, better yet, not scroll at all) given the
specified rows and page size.
This is loosely based on the same functionality in ZotFile, but it tries
to do the right thing based on existing Zotero settings: either the new
PDF handler setting in the prefs or the system-default app. The latter
can only reliably be determined on Windows (and this uses ZotFile's
function to read that from the registry), but this tries to figure it
out on macOS and Linux too using the Mozilla handler service. (The
handler service only gets you an app name, not a path, so on Linux we
can try reading mimetypes.list and the like in case someone is using a
system-default okular or evince not in /usr/bin, but that's not yet
implemented.)
This uses the new 5.0 URL format, and a 'page' query parameter instead
of a path component:
zotero://open-pdf/library/items/[itemKey]?page=[page]
zotero://open-pdf/groups/[groupID]/items/[itemKey]?page=[page]
It also accepts ZotFile-style URLs, though, so if you uninstall ZotFile
you should still be able to open those links. ZotFile will need to
accept the new format for new links to work when ZotFile is installed,
since it will override this handler.
This functionality will be necessary for annotation extraction (#1018)
and for imported annotations from Mendeley (#1451).
.contains() was removed in Firefox 48, but .includes() wasn't available until
40, so use indexOf() for now. We can start using .contains() once we no longer
need to support 38 ESR.
