TinyMCE triggers a focus on the window itself, which means that the
window steals focus when an attachment is created even if another Zotero
window is in front. Instead, do a manual focus in the external note
window, which is the one place I could find where we rely on it (though
there might be others).
Do cleanup on 'unload' rather than 'close' (which is limited to a click
on the close button and doesn't get called for win.close()) and clear
the queue after each test.
When Window is accessed from another scope (e.g., ItemTreeView), the
`let` somehow prevents Zotero_RecognizePDF_Dialog from showing up on the
Window object like all the other objects loaded via <script>.
Automatic renaming is now done for dragging of an external file onto an
item (as added in 7cb95f41) as well as dragging as a linked file,
dragging a non-native (not text or HTML) URL, "Attach Link to File…",
"Attach Stored Copy of File…", and "Retrieve Metadata for PDF". It only
applies if a single file is being added and if the parent item has no
non-HTML attachments. By default, the renaming only applies to PDFs, but
this can be changed with the renameAttachmentFiles.automatic.fileTypes
hidden pref.
A new General pref, "Automatically rename attachment files using parent
metadata", controls whether the renaming happens.
Files saved via web translators are renamed regardless of this pref,
because they would often be gibberish otherwise.
Closes#113
Check file-editing access for the group from the API before offering to
reset, update the filesEditable setting properly, and restart the sync
automatically after resetting.
Rather than requiring translators to explicitly set a referrer, as
proposed in #772 and #1375, this simply sets it to the URL where the
save button was triggered. This fixes the Project Euclid example
in #772. It's possible it won't fix all cases, since the translator might
build the URL manually or via an intermediate page, but hopefully it
will fix the majority of cases.
I guess there's a possibility that this would break something that
currently works, but it's hard to imagine a site would block based on
the wrong referrer from the right site and not block on no referrer.
Unlike #1375, this doesn't bother with the referrer for native downloads
(e.g., snapshots or images). The former probably don't need it, and the
latter should probably be switched to use `saveURI()` anyway.
This might also fixzotero/translators#523 (SSRN) if the translator
allowed it.
Closes#1375
In Firefox 52, `FileUtils.getFile()` tries to create the path to the
file even if the path array is empty. (In later versions (maybe in 54,
which we're using on macOS) it only does this if more than one path
component is provided.) We only need the special directory anyway, so we
can just use `getDir()`.
Follow-up to 4bbae6e17
We're now using Zotero.HTTP.request(), which does its own checking for
security errors, so there's no need to do WebDAV-specific checks (though
we could consider checking for Zotero.HTTP.SecurityError and showing
more specific messages, since a self-signed certificate is more likely
in the case of WebDAV).
If a server returns an invalid HTTP response (e.g., Content-Encoding:
gzip with a plaintext body, a.k.a. NS_ERROR_INVALID_CONTENT_ENCODING)
but we can still parse a 4xx or 5xx HTTP response code, use that for the
XHR status, since it might be enough for what we need to do (e.g.,
verify a 404 from a WebDAV server). This fixes a current problem with
Box [1].
Also fix a "msg is not defined" error when the XHR status is 0 but the
SSL connection is fine and include the channel and response status on
the UnexpectedStatusException object (though both of these would now
only happen on an invalid 2xx response, when the XHR status would remain
as 0).
[1] https://forums.zotero.org/discussion/comment/301014/#Comment_301014
