When you uninstall a plugin through the UI, XPIInstall:
1. Sets the plugin's `pendingUninstall` to true
2. Calls our onUninstalling() method
3. Waits for the Add-ons window to be closed
4. Actually uninstalls the plugin
5. Calls our onUninstalled() method
If you undo the uninstallation between steps 2 and 3, the remaining steps
instead look like:
3. Sets the plugin's `pendingUninstall` to false
4. Calls our onOperationCancelled() method
This commit changes our implementation of the bootstrapped plugin lifecycle so
that the shutdown and uninstall hooks are called from onUninstalling() (step 2).
If you close the Add-ons window without undoing, nothing more happens. The
plugin remains uninstalled. If you undo before closing, though, we call the
plugin's lifestyle hooks just as if it had been newly installed (unless it was
disabled before uninstallation, in which case we call install but not startup).
This mirrors the behavior of Firefox WebExtensions and makes things work more
like you'd expect: uninstalling a plugin immediately deactivates it, and undoing
activates it again.
- Fix mistaken reference to event.target (instead of currentTarget) in sync
function
- Move sync functions to fields for easier debugging - can't set a breakpoint
inside an inner function in the Firefox debugger
Fixes#3142
- Switch to Mozilla's Timer.jsm for timer functions in XPCOM scope
- Add setInterval/clearInterval/requestIdleCallback/cancelIdleCallback
- Add all timer functions to plugins sandbox
Firefox has switched on all platforms, Chrome and Edge on Windows use
"Settings", and we really don't want to have to say different things for
different platforms
ScienceDirect sometimes puts the `name` directive at the end of the Content-Type
header instead of in Content-Disposition. That isn't strictly spec-approved, but
there are other directives (`charset` and `boundary`) that can also be appended
to Content-Type per the spec. We want to strip them before looking for handlers.
https://forums.zotero.org/discussion/105194/sciencedirect-pdf-downloads-not-working-zotero-7
This was triggering an erroneous warning dialog about a failure to check
for Firefox profiles during Linux tests (where the profile is at
something like /tmp/tmp.l5phnqSxBH/Zotero), but it could also affect a
custom profile directory location.
- Set zotero-noteQuickCopy-menu's preference attribute to the correct key
- Warn about all ID-ish preference attribute values
- zotero-noteQuickCopy-menu's preference attribute was being set to the ID of
a now-nonexistent <preference> element. preference attribute values should
be preference keys now, but we were only warning if the associated
<preference> element was actually there
- We can't warn in all cases where the preference doesn't yet exist, because
some preferences don't have default values, and we shouldn't limit to
preferences that don't exist, because then the warning will stop showing
after the preference is persisted once
- When a <preference> ID is replaced by the associated key, update the
preference attribute so future syncFromPref() and syncToPrefOnModify() calls
will set the correct preference
- Listen to a range of events on all bound nodes, no matter their type
- Don't resolve _firstPaneLoadDeferred until actually done loading
Fixes#3131.
To run a short-lived command and return stdout
The Subprocess module can also start long-running process and
communicate with them, but we'll implement something different for that
if we need it.
(And update the en-US version with some strings that we don't use but
might if we updated to a slightly newer version of the updater before
they got rid of the dedicated update window)
If the file wasn't an XPI at all, or it didn't contain valid metadata for fx102,
the error message would previously show "%S" where the add-on name should be.
Now we fall back to the file path.
So a custom build doesn't have to modify each .ftl file
`app-name` is redundant with the Firefox strings, but it's what we used
previously and is easier to remember.
`nsIWebProgressListener.onStateChange()` gets called twice at the end of
requests, once with `stateFlags` set to `327696` and once with it set to
`262160`, which corresponds to `STATE_STOP + STATE_IS_NETWORK +
STATE_IS_REQUEST` and `STATE_STOP + STATE_IS_NETWORK`. httpd.js debug
logging shows that the connection is closed between the two calls. In
WebProgressFinishListener, we were previously calling `onFinish` after
the first one, but in Zotero 7, at least on Linux (or maybe just on
slower machines due to a race condition), the file from `saveURI()`
doesn't appear to be reliably written after the first call, causing
`Attachments.downloadFile()` to fail in `_enforcePDF()` due to an empty
file.
This changes WebProgressFinishListener to wait until the second
`STATE_STOP` call. We'll have to confirm whether this is the
state-change pattern for all requests, but it fixes our Find Available
PDF tests in CI.
https://firefox-source-docs.mozilla.org/dom/ioutils_migration.html
This also fixes a bug when `getContentsAsync()` is passed an
`nsIInputStream` or `nsIChannel` where raw bytes were returned instead
of a string. Not sure if we're doing that anywhere. If we are, this
would presumably break that code, but the function is supposed to return
a decoded string.
From some 2017-era langpacks I had downloaded. These strings aren't in
current langpacks, which use a different update mechanism, but we're
bundling a modified version of updates.xhtml from Firefox.
All declared Fluent files need to exist for a locale to be used (in a
window?). Since Mozilla code tries to load Fluent files, we need to copy
non-English Mozilla .ftl files to their default effective path (just in
the app omni.ja instead of the toolkit omni.ja).
Fixes#3094
https://forums.zotero.org/discussion/104431/syncing-problem
Replace Online Library can upload annotations created by others in a
group library, so if the upload resulted in a local write, "Cannot edit
item in library" was thrown, since annotations by others aren't
writable. This should've only been a problem if the uploaded data was
actually modified by the server, but we were also checking whether
objects were editable before checking if they had actually changed, so
it would happen for any upload of another person's annotation.
This fixes the order of checks when saving objects and makes an
edit-check exception for saving uploaded data for group annotations.
- Support removeHandler()
- Return DB items from translate() when called with libraryID
- Don't invoke done until attachments are done
Fixes#3084 ("after all" hook still times out, but that happens even if the test
is disabled)
HTML files are now indexed instead of read directly, and indexing was
previous skipped in tests and otherwise performed on a delay, so set a
flag in the affected tests that triggers inline indexing.
Having a single customElements.js file that we import everywhere we need it
helps with organization, and it gives us a single place to put things like the
<tab> fix.
We could switch to using setElementCreationCallback() like Firefox if the number
of imports gets out of hand, but the overhead right now should be small.
Prevents bug in zotero-citation plugin (at least on macOS) from creating
a search that breaks syncing
We were already checking for a missing name in `saveTx()`, but the
plugin is saving the same search twice in rapid succession, the second
time without a name, and the second attempt clears the search object's
name value after the first save's `_initSave()` check and before its SQL
write. The second save fails, but the first save goes through without a
name, resulting in a sync error.
https://forums.zotero.org/discussion/104274/id-1702002152-cannot-synchttps://github.com/MuiseDestiny/zotero-citation/issues/31
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
It does not appear to be possible to create a creator with no values in
Mendeley, however we got reports of these causing the imports to fail.
This tweak makes the importer more resilient by discarding empty/invalid
creators.
- Show "More information" link next to relink option
- Automatically check relink option when coming from integration prompt
- Change done message to "[x] items were relinked" instead of "0 items
were imported"
New option only appears if importer version is < 1 or not present.
It will:
* Skip fetching collections and attachments
* Skip any new items
* Update relations on existing items
* Importer will now ask user for a login and password via form and will
perform sign-in directly using credentials rather than oauth
* Signing in this way enables importer to obtain desktop document ID
which is now stored for each item
* It's possible to switch back to the old method (ouath) by setting
`import.mendeleyUseOAuth` pref to `true`.
* New option to only import new items. This options only appears if
database contains previously imported items.
* Importer will now update mendeleyDB:documentUUID on existing items to
match value used in Mendeley Desktop if available
* Importer will no longer create collections when no new items are
imported * Importer will only report number of new items imported on
re-import * Importer will now preserve dateAdded on re-import
Co-authored-by: Dan Stillman <dstillman@zotero.org>
- Windows global styles make .header bold, so we'll override them
- Prefix IDs in <notes-box>
- Give <tags-box> Add button a normal margin
- I think the CSS this removes was meant to apply to tags in the list, not the
Add button, but that's handled elsewhere now
Now all included in `itemFields.`
We still use base-only fields as search conditions, and schema.json
consumers might want to do so as well, so it makes sense to include
them.
This fixes an error using Everything if another library hasn't yet been
loaded and should speed up Everything searches for people with multiple
libraries.
This is sort of an awkward fix, because it doesn't fix the underlying
problem of `addCondition('libraryID', ...)` not working the same as
`.libraryID =` for some search conditions that perform subsearches. But
supporting `addCondition('libraryID', ...)` for those would get
complicated, because there could technically be multiple such
conditions, and applying those to a subsearch that used `AND` would get
messy. So let's just fix the problem at hand.
Fixes#3032
Or at least a way that we already have built-in and that only applies to
the call in `Zotero.Item::migrateExtraFields()`. This doesn't
distinguish between CSL fields (`publisher-place`, `event-place`,
`issued`) and actual Zotero field, and we really only need to skip
the former, but it's fine.
Follow-up to e3cfeee81, related to #3030
Removes a huge amount of excessive files and duplication for CE scss.
All CE css is now output in the single
zotero-react-client.css file.
Moving all CE styling into a single stylesheet required removing their
shadow DOMs. It is desirable anyway, since you want to
be able to style CEs from "outside", when embedding in different
contexts.
Shadow removal required some CE code changes to maintain
functionality.
Elements refactored:
- attachment-box (displayed when an attachment (like PDF) is selected in
the item tree)
- color-picker (in the tag color selector)
- guidance-panel (displayed on first run when editing authors for a book
section)
- item-box (info tab in the item pane)
- note-editor
- notes-box (note tab in the item pane)
- quick-search-textbox
- related-box (related tab in the item pane)
- tags-box (tags tab in the item pane)
- zoterosearch (advanced search condition builder form)
Setting a height/max-height was causing the window not to grow correctly when
rows were added. Whatever the purpose of those styles was in past FF versions,
they're no longer necessary now.
cfbfcf2 changed restore{To,From}Server to restore{To,From}OnlineLibrary and
updated most of the references, but not the ones in preferences_sync_reset.
Other languages still have those strings under the old key names.
- Add 'x' accesskey for "Exit" on Windows
- Show "Quit" instead of "Exit" on Linux
- Don't show Ctrl-Q for shortcut key on Windows
But Ctrl-Q still works on Windows when it shouldn't because of the Mac
keybinding, which still gets registered even if disabled
programmatically in platformKeys.js.
fx102 follow-up to #3010
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.)
People are confused by "Zotero Connector Server is Available". I'm not
sure if this will be any better, but not mentioning the connector might
help -- that seems to be part of the problem.
We could display a longer message with a link to
https://www.zotero.org/support/kb/connector_zotero_unavailable, but this
is the /ping page that gets hit constantly, so it seems like we should
keep it short (though probably it doesn't make a difference).
- Word for Windows not tested since there's no build yet
- Word for Mac currently causes a sigsev, and likely we'll see this on
windows too. This is happening on an API call where we pass a callback,
so likely an issue in ctypes that we'll have to work around.
- All integration UIs restored.
- Added a component for richlistitems with a checkbox with corresponding
interactions (spacebar/double-click to toggle).
Fixes the issue when your own created annotation becomes grayish and indicates that it was modified by another user.
(cherry picked from commit 4dd1851140)
Having the macOS Help button in a scrolling view feels kind of weird, but that's
what Apple is doing in the Ventura System Settings app, so I guess we go with
it. I like it better than Firefox's non-contextual "Firefox Support" button
under the pane list in their preferences, anyway - having pane-by-pane
contextual help buttons seems like good UX that there isn't a good reason for us
to ditch.
- 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.
To allow creation of a standalone note with annotations from all the
selected top-level items and/or attachments. Annotations will be sorted
by the order of the items in the items list.
"Add Note from Annotations" remains when a single regular item or one or
more attachments under a single regular item are selected.
So that it works for more than two levels of items
Also fix a bug where the parent item could be returned more than once if
multiple child items were selected.
