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).
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()`
Pressing Ctrl-C via the terminal is counted as a crash, and after three
recent crashes automatic safe mode is triggered. In Firefox, this
displays a prompt:
> Firefox closed unexpectedly while starting. This might be caused by
> add-ons or other problems. You can try to resolve the problem by
> troubleshooting in Safe Mode.
For us, that dialog doesn't appear for some reason (maybe we could make
it?) and Zotero just automatically opens in Safe Mode, which causes
state not to be restored and results in an annoying process fork that
breaks Ctrl-C. We might as well keep the automatic-safe-mode behavior
for end users, but we don't want to trigger it while working via the
terminal, so we just clear the recent crash counter when using
`-ZoteroDebug` or `-ZoteroDebugText`. (`extensions.zotero.debug.log`
won't trigger it, so it's best to use `-ZoteroDebugText`, which is
included automatically via the `build_and_run` script.)
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
bb220ad0f2...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
But skip it at startup, even if flagged on, if there are schema update
steps to perform, to avoid creating tables that aren't expected to exist
yet.
Originally added in 5b9e6497a but disabled in c4cc44528 and 7a434df53
- The Mozilla CommonJS loader is no longer available, so bundle the
Fx52 version of it
- Strict mode is enforced
- `this` is only defined as a global object in .jsm files, not .js files
- `this` can't be converted to a string for BackstagePass test, so check
for presence of Components.utils.import instead
- The return value from import() is no longer available
- Check for retracted items using data from Retraction Watch
- Show an X next to retracted items in the items list, and show a
scary message at the top of the item pane with more info and links.
- Lookup is done in a privacy-preserving manner using k-anonymity --
the server is unable to determine the specific items that exist in
the client, so people who don't sync don't need to share any library
data (though the server doesn't log the lookups anyway).
TODO:
- Pop up an alert when new items are found
- Show a confirmation prompt when citing a retracted item
- Support items without DOIs or PMIDs
- Add a proper PMID field and expand DOI to more item types so these
values don't need to be parsed out of Extra
- Clear the banner immediately when all possible fields are cleared
instead of waiting a few seconds
Currently only .status and .getResponseHeader() (for getting 'Location')
are available in the returned object, but we could make the body
available if necessary.
Move `Zotero.getString()` and intl init code to `Zotero.intl` to make
it easier to re-use.
Link `Zotero.getString()` to `Zotero.intl.getString()`.
Do not expose `getStringFromBundle`, `pluralFormGet`, and
`pluralFormNumForms` because they are not used.
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).
And fix deprecation warning from passing an nsIFile
(Also updates the Zotero.Styles.install() documentation to note that the
first parameter's `file` property can be a string path.)
Can be an absolute path or 'profile' to use 'zotero' subdirectory of
profile directory as in earlier versions (but which won't be treated as
a legacy location eligible for migration)
Closes#1305
We were manually looking up the current locale in various places and
passing it to nsIStringBundleService::createBundle(), but that hasn't
even been a supported argument for years. (I assume it was a long time
ago?)
