Improvements:
- Fixes autocomplete text remaining in field after selection in Fx60
- No more text or icon shifting on select (tested on macOS)
Changes:
- Tags are now selected on mousedown with no active state, as in web
library
Regressions:
- Tooltip with tag type doesn't appear when hovering over icon
- Pressing Tab after modifying a tag loses focus
- Right-click in textbox shows custom menu instead of default text
editing context menu (Cut/Copy/Paste)
To-do:
- Switch to this version for note tags box
- Style colored tags in autocomplete drop-down? Sort to top?
- Only show delete button on row hover, as in web library?
When browserifying anything that depends on React, don't bundle another
copy of React in the file. There might be some other common dependencies
that we should include here.
`intl.regional_prefs.use_os_locales` isn't actually equivalent to
`intl.locale.matchOS` -- an empty string for `intl.locale.requested` is,
and that's set by calling `setRequestedLocales(null)`.
Mozilla documentation:
https://firefox-source-docs.mozilla.org/intl/locale.html
- When upgrading from Fx52, don't show "Automatic" for
a manually selected locale.
- Make sure Zotero.locale is always set to a known language tag
- Fix inconsistencies between Zotero.Locale.availableLocales and
chrome.manifest
When we added the View menu pane options in 3aeef69ad3, we removed
automatic reopening of the panes on startup, since the View menu is more
discoverable than the narrow collapsed splitters. Unfortunately we're
now getting many reports of people not knowing where their panes are.
It turns out the View menu pane options in 5.0.76 are actually broken,
so it's not a great test, but enough people are doing this by accident
and enough of them don't seem to be finding the View menu options
(broken or otherwise) that I think it's better to return to reopening
the panes. We can always add a hidden pref to change that behavior, but
no one has complained in years, so it's probably not necessary.
This was a regression from 4b60c6ca27. The original plan for introducing
new fields was to have them save to the sync cache even if they weren't
supported by the current Zotero version and process them on upgrade, and
so I changed `DataObjectUtilities.patch()` to omit fields that didn't
exist locally when patching the sync cache JSON so they wouldn't be
wiped on the server. That caused this bug where locally deleted fields
were restored on every sync. It's also no longer necessary now that
we decided to just reject unknown fields from saving, so we can just
revert to the previous behavior of blanking out locally missing fields
(with the tweak that fields that are already false or empty in the base
version can be omitted).
- Include file path
- Show separate message for linked files mentioning Linked Attachment
Base Directory
- Link to separate support page for linked files
And fix a couple things for if we turn it back on
This code came along with the type/field handling overhaul, but I think
it was originally intended for handling unknown fields during sync
before we decided on strict mode, so it wasn't finished and causes
various problems [1]. It could still be useful for preserving fields
from translators before they're available on items, but the better fix
there is just to add the missing fields, so I'm not sure if we'll end up
needing it.
[1] https://groups.google.com/d/msg/zotero-dev/a1IPUJ2m_3s/hfmdK2P3BwAJ
