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
- Use locale directories for JSON files, since that's where the
Transifex client will interact with them
- Skip non-locale directories (e.g., don't create an .ftl file for
.DS_Store)
- Other minor simplification
- 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.
In Firefox 102, `-file` was being swallowed by `nsBrowserContentHandler`
in BrowserContentHandler.jsm, so ab7d916e0 overrode that by using the
same contract id for our main nsICommandLineHandler in
zotero-service.js. But `nsBrowserContentHandler` also handles `-chrome`,
which we were using in tests to pass runtests.html. There's no need to
pass in dynamically though -- we can just hard-code that and open the
window ourselves.
