- Switch to Mozilla's Timer.jsm for timer functions in XPCOM scope
- Add setInterval/clearInterval/requestIdleCallback/cancelIdleCallback
- Add all timer functions to plugins sandbox
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.
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
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
- Limit field autocomplete to current library in item pane (previously
only done for creator and access date)
- Improve positional parameter usage to avoid duplicate parameters
- Code cleanup
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.
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
I'm not totally sure why we didn't do this years ago, but this fixes
performances problems in the new React tags box, and should improve
autocomplete performance generally in large libraries.
