PDF-handling code from `ZoteroPane.viewAttachment()` predates
`Zotero.OpenPDF` and didn't handle page numbers for external PDF
readers, so when called from "Show on Page" in a note (via
`ZoteroPane.viewPDF()`) it just launched the file itself in the
specified handler or via the OS.
For now, change to use `Zotero.OpenPDF.openToPage()` when there's a page
number. Later we should use `Zotero.OpenPDF` for everything, but that
code is more complicated than just using `launchFile()`, so we'll need
to do some testing (particularly on Linux) to see what's best.
(Note that "Show on Page" with an external reader doesn't make a ton of
sense, since you can't actually see the annotation, but opening the
right page is better than nothing.)
Fixes#2612
And remove all references to old id
We can do this because plugins will use new mechanisms for install and
update manifests that don't use the id (which also means it's now only
used internally).
We'll want to update the rest of the instances of "extensions" or
"add-ons" to say "plugins" (unless we think we might support themes, in
which case we can keep "add-ons").
_getFieldValue() and _setFieldValue() were using `.value` instead of
`.textContent`, so the few places that use it were getting/setting ignored
fields on divs.
fbc25834 messed up the tab index logic, shifting the responsibility for
preserving _lastTabIndex across refreshes: originally, the default was to throw
it away, and the caller was responsible for saving and restoring it if the
refresh was caused by tabbing between fields. The bad commit reversed the
situation and made the item box *remember* the _lastTabIndex by default,
meaning that a refresh caused by the notifier, for example, would focus the
last focused field even if it had been closed by the user in the meantime.
That bad change was a misguided attempt to fix the Tab key cycling infinitely
between Item Type, Title, and creators and never reaching further fields. The
actual fix was just to add `, textarea` to the query on line 1459.
All already being handled by CSS (besides the exact character length limits, but
it's not clear that we really need those - we just ellipsize if it visually
overflows now, which seems fine).
Plugins are ZIPs containing at least these two files:
- manifest.json: A WebExtension MV2 manifest with basic metadata
properties and `applications.gecko` with `id` and `update_url`
- bootstrap.js: A bootstrap file, similar to old bootstrapped extensions,
with `installed()`, `startup()`, `shutdown()`, and `uninstalled()`
The fieldMode attribute of the input was being set by the call to
switchCreatorMode(), but it didn't carry over to the label that replaces it on
line 1997.
Also removed a debug line and cleaned up a bit.
Not the exact same sizing as Fx60, because that relied on some quirks
of the Mozilla box model that I can't reproduce with flexbox, but still
works about as well.
Hasn't done anything since in-browser viewing of certain file types in
Zotero 4 for Firefox. Perhaps we'd bring it back at some point, but
disable for now.
Hasn't been relevant since the Firefox NPAPI days, but was returning
true for `application/pdf` (possibly due to the bundled pdf.js in
Firefox still being included in our builds, which we should remove if
so), which was causing "Open in External Viewer" to appear, even though
it just opened the internal reader.
