Well this was a wild one to debug.
Creator fields were only initialized for autocomplete due to a series of
>10-year-old bugs:
1) In `showEditor()`, `Zotero.ItemFields.isAutocompleteField(fieldName)`
was called for creator fields, which would pass, e.g.,
`creator-0-lastName`.
2) In `isAutocompleteField()`, `ItemFields.getName()` would normalize
`creator-0-lastName` to `false`, since it's not a valid field.
3) `isAutocompleteField()` listed `place` as a base field despite its
not having any mapped fields, so when `getTypeFieldsFromBase()` was
called on it, the return value would be `false`, which would be added
to the list of autocomplete fields, which would mean that the
normalized field of `false` from `creator-0-lastName` would match,
which would mean that `isAutocompleteField('creator-0-lastName')`
would always return true...as long as `place` never gained a mapped
field.
Except `isAutocompleteField()` wasn't supposed to be the test for
initializing autocomplete for creator fields anyway -- `fieldName ==
'creator'` was. But `fieldName` is something like `creator-0-lastName`,
not `creator`, which meant that that test always failed, which meant
that if `place` did gain a mapped field, both tests would fail, which
would cause the creator field not to be initialized for autocomplete,
which would cause it to break as soon as you started to type into it.
This fixes that.
Panes were being loaded with Zotero_Preferences as their global scope, so global
variables they defined would be set on that object instead of the window.
The file should follow the same `pref("extensions.foo.bar", "value");`
syntax as files previously in defaults/preferences/, which should no
longer be used in Zotero 7. (For an extension that works in both Zotero
6 and 7, it's OK to have a file in defaults/preferences for Zotero 6 and
an identical prefs.js for Zotero 7.)
Files in defaults/preferences/ aren't automatically loaded when a plugin
is installed/enabled but are still loaded at app startup by Mozilla code
for now. Plugins shouldn't count on that continuing to be the case in
Zotero 7 and should switch to prefs.js.
We'll add a way for bootstrapped plugins to manually trigger reading of
a prefs.js file in Zotero 6.
Using the Headers class from the Fetch API.
Before, the added test would fail: `_requestInternal()`, not finding a header
named `Content-Type` (case sensitive), would set it to
`application/x-www-form-urlencoded`. XMLHttpRequest, upon being given both
`content-type`: `application/json`) and `Content-Type`:
`application/x-www-form-urlencoded`, would helpfully merge the two, producing
`content-type`: `application/json, application/x-www-form-urlencoded`. That's
obviously not the correct behavior.
Limited to a hard-coded list
Initially limited to `extensions.zotero.import.mendeleyUseOAuth`,
to switch the Mendeley importer from direct login to OAuth
Services.locale always wants an array now, but it can be empty.
We still get "Uncaught (in promise) undefined" printed to the console, no stack,
not caught by "Pause on exceptions" in the debugger... but it's not clear that
that's actually coming from this code, and it doesn't seem to prevent anything
from working.
- Don't rely on Zotero.hiDPISuffix being initialized in menuToolbarbutton.js --
it probably hasn't been at the time that the code that creates the dropmarker
is running
- Fix merge mistake that created a duplicate block of CSS
- Render cell text in its native direction
- Fix context menu positioning
- Fix item box (localizations needed)
- Fix column resizing
- Fix bidi text in collection tree
- Always right-align in RTL, always left-align in LTR.
I'm going off advice from this excellent guide for RTL website design
by Ahmad Shadeed: https://rtlstyling.com/posts/rtl-styling#tables
- Join creators in the tree ("Smith and Jones") using a format string to
support languages like Arabic and Hebrew where there shouldn't be a
space after the "and".
- Fix tabs
- Fix toolbar on Mac, flip icons on other platforms
When enabled:
- Double-clicking a PDF or choosing "Open PDF" opens a new window
- Shift-double-clicking opens a new tab
- "Open in New Window" locate option becomes "Open in New Tab" and has the
reverse behavior
Previously cookies only got attached on the initial request but not on
any redirect and subsequent request. This may have been the cause for
many reports of import failures behind proxies in the past.
Technically this code has been wrong for a long time, but it only
manifest now. It seems that the equivalent code in translate module
was fixed when that code was extracted into a separate repo
- Correct padding and don't use Mozilla preferences styles
- Fixed v-t issue that applied the wrong class names to columns, giving them
incorrect widths
In this case, Note Markdown wouldn't be preloaded, but it's always used
for copying from the note editor, and since the note editor uses
`noWait`, this would result in "Code promise is not resolved in noWait
mode".
Zotero.Translators.reinit() didn't reinit Quick Copy, so if an export
translator was selected it wouldn't be preloaded again and dragging
would fail with "Code promise is not resolved in noWait mode".
Find Available PDF has its own domain-based retry logic that predated
automatic 5xx retries in Zotero.HTTP, so disable the latter and fix some
bugs in the former.
Fixes#2700
Also:
- Hide format options until translators are loaded (since otherwise
the checkboxes don't have labels and the layout is messed up)
- Remove unnecessary "zotero-" prefix from the new elements
The default JSON pref value used spaces, but changing the drop-down
resulted in a version without spaces, so simply changing the default to
include the new link options wouldn't change all existing installs and
the "Include App Links" checkbox wouldn't show as enabled for Markdown.
This adds a pref migration step to reset the pref to the new default if
it's set to Markdown + Rich Text, regardless of whitespace differences.
And just fully reload the preferences window when the pane array changes. The
preferences window won't often be open when a plugin is enabled or disabled,
considering that the Add-ons window is external to the preferences, and trying
to add/remove panes dynamically without reloading brings lots of bugs.
(No way to dynamically remove a script, for one.)
