Updates needed for Zotero plugins

[Dan Stillman]

We'll soon be updating Zotero's underlying platform from Firefox 52 ESR
to Firefox 60 ESR.

This allows us to meet the new app notarization requirements in macOS
Catalina [1], coming in September, and it also provides us with all the
improvements that came between Firefox 52 and 60, including the
performance improvements in Firefox 57 (though we haven't yet tested how
much those affect us).

Unfortunately, this upgrade will require most Zotero plugins to be
updated, though Zotero's own updates should serve as a fairly
comprehensive roadmap.

You can see a list of all the Zotero changes here:

https://github.com/zotero/zotero/compare/master...fx60

Build changes (probably only relevant to Jurism) are here:

https://github.com/zotero/zotero-standalone-build/compare/master...fx60

Most plugins hopefully won't encounter most of this, but here are some
highlights that may come up:

- Old-style Mozilla shorthand function definitions should be replaced
with arrow functions
(https://github.com/zotero/zotero/commit/9ca1014f5bc90b6edabb5f04b3f73df09fdb246a)

- `nsILocalFile` should be changed to `nsIFile` or replaced with strings
paths or `Zotero.File.pathToFile()`
(https://github.com/zotero/zotero/commit/433794916a493d68cc793fd8fa577e2db5ad3efe)

- `nsIFilePicker::show()` was removed in favor of `.open(callback)`, but
we added a replacement `FilePicker` module with an `await fp.show()`that
should be used instead
(https://github.com/zotero/zotero/commit/6f965251ed8eea160f95edaa8274c1bd786fafdc)

- `nsIURI` is now immutable, so you have to use
`uri.mutate().setFilePath(uri.filePath + '/foo').finalize()` or similar
to make a new URI with modifications
(https://github.com/zotero/zotero/commit/61e976bd3aec95b73cd993e685adfa897ab3784f)

- `nsIURI::path` is now `nsIURI::pathQueryRef`

- `prefwindow` and related XBL bindings were removed, but we've restored
them for now. If you have a preferences window, you need to include an
additional CSS file.
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- The `Zotero.File.iterateDirectory()` signature changed
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- XMLHttpRequest is now just `new XMLHttpRequest()` even in XPCOM
(https://github.com/zotero/zotero/commit/6fd879fc16552b3a16a5cbad0a74cb19baf15a35)

We've put up test builds on a dev channel that you can use to test and
update your plugins:

https://download.zotero.org/client/dev/5.0.75-dev.1%2B2a613258e/Zotero-5.0.75-dev.1%2B2a613258e.dmg
https://download.zotero.org/client/dev/5.0.75-dev.1%2B2a613258e/Zotero-5.0.75-dev.1%2B2a613258e_linux-x86_64.tar.bz2
https://download.zotero.org/client/dev/5.0.75-dev.1%2B2a613258e/Zotero-5.0.75-dev.1%2B2a613258e_win32.zip

(This channel won't be active most of the time, so you shouldn't expect
to stay on it after this development cycle.)

We need to push this branch to the beta channel at the end of next week
so that it gets sufficient testing, so you'll need to update your
plugins by then for them to continue working for beta users. Catalina
will probably come out September 23rd, so we need to have at least the
Mac version in production by then.

Sorry for the late notice here. The current version of Zotero works
essentially fine on Catalina, and we weren't anticipating the
notarization changes to require a platform upgrade, but that ended up
being the least-annoying option. We're happy to work with plugin
developers over the next couple weeks to make sure plugins are updated
in time, and other plugin developers may be willing to pitch in as well,
so please post here if you don't think you'll be able to finish on time.
Also feel free to post here or CC me on GitHub if anything is unclear
from the Zotero commits or if you run into other incompatibilities.

- Dan


[1]
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

[Dan Stillman]

On 8/28/19 6:44 AM, Dan Stillman wrote:
> - The `Zotero.File.iterateDirectory()` signature changed
> (https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

Correct link:
https://github.com/zotero/zotero/commit/8fa4cc9387b5502c51b93552c91136df711ce5b8

[Emiliano Heyns]

On Wednesday, August 28, 2019 at 12:44:15 PM UTC+2, Dan Stillman wrote:

 

 

- `nsIFilePicker::show()` was removed in favor of `.open(callback)`, but
we added a replacement `FilePicker` module with an `await fp.show()`that
should be used instead
(https://github.com/zotero/zotero/commit/6f965251ed8eea160f95edaa8274c1bd786fafdc)

How should I use this from a plugin? I won't be able to do "import FilePicker from 'zotero/filePicker'"

 

- `prefwindow` and related XBL bindings were removed, but we've restored
them for now. If you have a preferences window, you need to include an
additional CSS file.
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- The `Zotero.File.iterateDirectory()` signature changed
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- XMLHttpRequest is now just `new XMLHttpRequest()` even in XPCOM
(https://github.com/zotero/zotero/commit/6fd879fc16552b3a16a5cbad0a74cb19baf15a35)

Are these changes new to FF60? Or were they available on FF52 and are the older alternatives being deprecated? Should I expect these changes to work on FF52?

[Dan Stillman]

On 8/28/19 11:02 AM, Emiliano Heyns wrote:

On Wednesday, August 28, 2019 at 12:44:15 PM UTC+2, Dan Stillman wrote:

 

- `nsIFilePicker::show()` was removed in favor of `.open(callback)`, but
we added a replacement `FilePicker` module with an `await fp.show()`that
should be used instead
(https://github.com/zotero/zotero/commit/6f965251ed8eea160f95edaa8274c1bd786fafdc)

How should I use this from a plugin? I won't be able to do "import FilePicker from 'zotero/filePicker'"

You can if you use Babel. Otherwise you'd need to use`var FilePicker = require('zotero/filePicker').default;`.

(You can also just use nsIFilePicker with open(callback), but you'd need to change that again in the future.)

- `prefwindow` and related XBL bindings were removed, but we've restored
them for now. If you have a preferences window, you need to include an
additional CSS file.
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- The `Zotero.File.iterateDirectory()` signature changed
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- XMLHttpRequest is now just `new XMLHttpRequest()` even in XPCOM
(https://github.com/zotero/zotero/commit/6fd879fc16552b3a16a5cbad0a74cb19baf15a35)

Are these changes new to FF60? Or were they available on FF52 and are the older alternatives being deprecated? Should I expect these changes to work on FF52?

Good question.

Many of the Firefox changes (e.g., `new XMLHttpRequest()`) are older and should work in Fx52 Zotero.

For others, including the Zotero-side changes like iterateDirectory(), for the time being you'll need to check Zotero.platformMajorVersion to see if you're in 52 or 60.

Let me know if anything seems problematic in terms of fixing while Fx52 Zotero is still out.

[Emiliano Heyns]

On Thursday, August 29, 2019 at 7:59:40 AM UTC+2, Dan Stillman wrote:

On 8/28/19 11:02 AM, Emiliano Heyns wrote:

On Wednesday, August 28, 2019 at 12:44:15 PM UTC+2, Dan Stillman wrote:

 

- `nsIFilePicker::show()` was removed in favor of `.open(callback)`, but
we added a replacement `FilePicker` module with an `await fp.show()`that
should be used instead
(https://github.com/zotero/zotero/commit/6f965251ed8eea160f95edaa8274c1bd786fafdc)

How should I use this from a plugin? I won't be able to do "import FilePicker from 'zotero/filePicker'"

You can if you use Babel. Otherwise you'd need to use`var FilePicker = require('zotero/filePicker').default;`.

I use typescript so I can use import, but I had forgotten Zotero has its own require implementation. I use webpack so I can only require modules that can be found at build time. It's OK, I'll just use the open(callback) version.

 

(You can also just use nsIFilePicker with open(callback), but you'd need to change that again in the future.)

I guess that'll be required then, unless FilePicker becomes available under the Zotero object somewhere.

 

Good question.

Many of the Firefox changes (e.g., `new XMLHttpRequest()`) are older and should work in Fx52 Zotero.

For others, including the Zotero-side changes like iterateDirectory(), for the time being you'll need to check Zotero.platformMajorVersion to see if you're in 52 or 60.

I don't use that, and the other changes have just passed my test suite on the current Zotero, so all looks good.

[Will S]

On Wednesday, August 28, 2019 at 6:44:15 AM UTC-4, Dan Stillman wrote:

Sorry for the late notice here. The current version of Zotero works
essentially fine on Catalina, and we weren't anticipating the
notarization changes to require a platform upgrade, but that ended up
being the least-annoying option. We're happy to work with plugin
developers over the next couple weeks to make sure plugins are updated
in time, and other plugin developers may be willing to pitch in as well,
so please post here if you don't think you'll be able to finish on time.
Also feel free to post here or CC me on GitHub if anything is unclear
from the Zotero commits or if you run into other incompatibilities.

- Dan 

A couple addons related things I noticed while testing with the beta:

1. The Add-ons Manager did not have a back button any more. So if I clicked on "More" on an addon, I needed to close and re-open the window to go back.

2. There was no more preferences button in the addon listing. I guess this is because Firefox 60 does not support it. My addons already add items to the Tools menu to open their preferences windows, so it is not a big deal, but I am just noting it.

[Will S]

In updating my overlay addon (https://github.com/willsALMANJ/lyz), I found that default preferences in the defaults/ directory were not loaded. Maybe there is a way to make them work. I just refactored to set the default preferences dynamically when the addon is loaded like I was already doing for my bootstrapped addon (https://github.com/willsALMANJ/Zutilo). (Otherwise, I think I converted LyZ to Zotero 5.0.75 as well now -- in testing I occasionally saw error messages about the file paths it uses to read/write data from LyX through a named pipe, but everything seemed to work even when the error messages appeared).

I don't write any Javascript outside of my Zotero plugins, so maybe you can help me understand some details that I am not sure about. From back when Zotero first started using async, I have several methods wrapped in Zotero.Promise.coroutine so I can yield to async Zotero methods. Now some of the newer Zotero functions (like the new FilePicker that I switched to using) use async/await. From my testing, these two methods seem to be interchangeable: I can yield to async functions inside of coroutines and I can await coroutines inside of async functions. Is that right?

[Dan Stillman]

On 9/7/19 3:04 PM, Will S wrote:
> A couple addons related things I noticed while testing with the beta:
>
> 1. The Add-ons Manager did not have a back button any more. So if I
> clicked on "More" on an addon, I needed to close and re-open the
> window to go back.

I haven't tested much on Windows or Linux, but do you not still have an
Extension tab on the left-hand side that you can click to get back to
the main view? That works for me on macOS.

> 2. There was no more preferences button in the addon listing. I guess
> this is because Firefox 60 does not support it. My addons already add
> items to the Tools menu to open their preferences windows, so it is
> not a big deal, but I am just noting it.

Ah, yeah, that does appear to be the case. We'll look into adding that
back, but you're right that it's easy for plugins to work around, and
many/most probably already do.

[Will S]

On Monday, September 9, 2019 at 11:53:50 PM UTC-4, Dan Stillman wrote:

I haven't tested much on Windows or Linux, but do you not still have an
Extension tab on the left-hand side that you can click to get back to
the main view? That works for me on macOS.

I hadn't tried that -- yes, you're right. That does work on Linux as well.

[Dan Stillman]

On 9/9/19 3:31 PM, Will S wrote:
> In updating my overlay addon (https://github.com/willsALMANJ/lyz), I
> found that default preferences in the defaults/ directory were not
> loaded. Maybe there is a way to make them work. I just refactored to
> set the default preferences dynamically when the addon is loaded like
> I was already doing for my bootstrapped addon
> (https://github.com/willsALMANJ/Zutilo). (Otherwise, I think I
> converted LyZ to Zotero 5.0.75 as well now -- in testing I
> occasionally saw error messages about the file paths it uses to
> read/write data from LyX through a named pipe, but everything seemed
> to work even when the error messages appeared).

Oh, extension default prefs may have been discontinued. I had noticed
that default preferences from our bundled word processor plugin
extensions weren't being used (and I moved those into the core defaults
at build time), but default prefs probably just aren't used for any
extensions anymore, since they're not used by WebExtensions or Mozilla's
system extensions.

So then yes, setting those dynamically at startup when they're not set
is probably what everyone will need to do.

> I don't write any Javascript outside of my Zotero plugins, so maybe
> you can help me understand some details that I am not sure about. From
> back when Zotero first started using async, I have several methods
> wrapped in Zotero.Promise.coroutine so I can yield to async Zotero
> methods. Now some of the newer Zotero functions (like the new
> FilePicker that I switched to using) use async/await. From my testing,
> these two methods seem to be interchangeable: I can yield to async
> functions inside of coroutines and I can await coroutines inside of
> async functions. Is that right?

Yes, that's basically right. Technically, Zotero.Promise.coroutine() is
Bluebird, whereas async/await use native promises, so if your code was
relying on some of the extra features of Bluebird promises (`.return()`,
`.spread()`, etc.), you could get an error in the calling code if the
called function was switched from coroutine() to async. But even in core
Zotero code that's very rare and generally has been trivial to work
around, since many Bluebird features are just syntactic sugar.

[Emiliano Heyns]

On Tuesday, September 10, 2019 at 7:07:28 AM UTC+2, Dan Stillman wrote:

On 9/9/19 3:31 PM, Will S wrote:
> In updating my overlay addon (https://github.com/willsALMANJ/lyz), I
> found that default preferences in the defaults/ directory were not
> loaded. Maybe there is a way to make them work. I just refactored to
> set the default preferences dynamically when the addon is loaded like
> I was already doing for my bootstrapped addon
> (https://github.com/willsALMANJ/Zutilo). (Otherwise, I think I
> converted LyZ to Zotero 5.0.75 as well now -- in testing I
> occasionally saw error messages about the file paths it uses to
> read/write data from LyX through a named pipe, but everything seemed
> to work even when the error messages appeared).

Oh, extension default prefs may have been discontinued. I had noticed
that default preferences from our bundled word processor plugin
extensions weren't being used (and I moved those into the core defaults
at build time), but default prefs probably just aren't used for any
extensions anymore, since they're not used by WebExtensions or Mozilla's
system extensions.

Wait what? Does that mean that defaults/preferences/defaults.js are not loaded anymore?

[Dan Stillman]

That's what it seems like, yes.

[Emiliano Heyns]

That's not great. When options are not set, will they be of type undefined?

[Emiliano Heyns]

In what way have defaults prefs been moved to build time? I will have to do something similar.

[Dan Stillman]

On 9/10/19 3:21 PM, Emiliano Heyns wrote:
> That's not great. When options are not set, will they be of type undefined?

Yes.

[Dan Stillman]

On 9/10/19 3:23 PM, Emiliano Heyns wrote:
> In what way have defaults prefs been moved to build time? I will have to do something similar.

You can't. I'm saying that, for the bundled extensions, we're copying
the extensions' defaults prefs to the app's default prefs.

In a plugin, you would need to set prefs that aren't yet set at startup,
as Will is doing for Zutilo.

But maybe we can provide a Zotero.Prefs.registerDefaultPrefs() that
takes an object with pref-to-default-value mappings, such that
subsequent .get() calls on those would fall back to the provided values
if a value wasn't set. That would avoid the need for every plugin to
implement a custom solution and pollute prefs.js with set values for
every possible pref. Maybe we can even enumerate the installed plugins
and parse the defaults file ourselves. I'll look into that, so hold off
for now.

[Dan Stillman]

On 8/28/19 6:44 AM, Dan Stillman wrote:

> We need to push this branch to the beta channel at the end of next
> week so that it gets sufficient testing, so you'll need to update your
> plugins by then for them to continue working for beta users. Catalina
> will probably come out September 23rd, so we need to have at least the
> Mac version in production by then.

Apple relaxed notarization requirements until January [1], so we were
able to notarize the current Mac build. This means we can take a bit
more time on the Fx60 upgrade.

We'll post an update when we have a date for pushing out Fx60 to beta.

[1] https://developer.apple.com/news/?id=09032019a

[Emiliano Heyns]

Ah, got it.

Settings pref defaults when undefined would be trivial for me, and for one particular case in BBT, better than how I'm doing it right now. But I can also wait it out. BBT just has the current assumption that none of its prefs are undefined.

[Brenton Wiernik]

If Zotero could enumerate plug-ins and set default prefs, that would definitely be preferable on my end.

[Dan Stillman]

We've made another big change on the dev branch that may require changes
in third-party code:

https://github.com/zotero/zotero/commit/4b60c6ca275ec69249b3ea81a669ae4823678d03

As noted there, hopefully the sole consequence for third-party code will
be that any hard-coded ids for item types, item fields, and creator
types will need to be replaced with appropriate function calls. For
example, if you have `1` for the note itemTypeID, you'll need to replace
that with `Zotero.ItemTypes.getID('note')`.

(Just to note, this commit renders the DB backwards incompatible.)

[Dan Stillman]

OK, in 5.0.75-dev.5, Zotero will read in default prefs from extensions.

It's possible parts of your plugin could load before the default
preferences are read in, so (for this and other things) you should wait
for Zotero.Schema.schemaUpdatePromise or Zotero.uiReadyPromise before
initializing.

If you're not already, consider using Zotero.Prefs.get(name,
global)/.set(name, value, global) rather than using Services.prefs
directly. That will fix breakage in Fx60 from Mozilla changes and be
future-proof in general. Just be sure to pass `true` for `global` to
indicate that you're referring to a global preference instead of
something under `extensions.zotero.`. I've also added a `global`
parameter to Zotero.Prefs.registerObserver(name, handler, global) to
make that usable by plugins in lieu of nsIPrefBranch.addObserver().
(Pass the returned Symbol to unregisterObserver(symbol) to stop watching.)

I didn't test this with all plugins, so let me know if anything seems amiss.

- Dan

[Frank Bennett]

Just starting the work to adapt Jurism to the fx60 build. I've hit a snag in the first build:

-----

Could not read 'file:///media/storage/src/JM/zotero-standalone-build/staging/Jurism_linux-x86_64/extensions/zoteroOpenOff...@zotero.org/components/zoteroIntegration.xpt'.
-----

The LibreOffice integration plug has only a master branch, and I have the tip set in the zotero-standalone-build submodule.

Looking at zotero-libreoffice-integration/master, there is indeed an entry for zoteroIntegration.xpt in chrome.manifest, and the file is not in the repo.

Not sure whether the line should be removed or the file restored?

Frank

[Frank Bennett]

Well actually, there seems to be a deeper problem with what I'm doing. This is the first-issued build error:

-----

1569026796193 addons.xpi WARN List of valid built-in add-ons could not be parsed.: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXPCComponents_Utils.readUTF8URI]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm :: _readAddons :: line 6415"  data: no] Stack trace: _readAddons()@resource://gre/modules/addons/XPIProvider.jsm:6415

getAddonLocations()@resource://gre/modules/addons/XPIProvider.jsm:6076

getInstallState()@resource://gre/modules/addons/XPIProvider.jsm:1594

checkForChanges()@resource://gre/modules/addons/XPIProvider.jsm:3230

startup()@resource://gre/modules/addons/XPIProvider.jsm:2196

callProvider()@resource://gre/modules/AddonManager.jsm:253

_startProvider()@resource://gre/modules/AddonManager.jsm:728

startup()@resource://gre/modules/AddonManager.jsm:892

startup()@resource://gre/modules/AddonManager.jsm:2981

observe()@jar:file:///media/storage/src/JM/zotero-standalone-build/staging/Jurism_linux-x86_64/omni.ja!/components/addonManager.js:63

-----

Something pretty fundamental is blowing up -- I get this even when no plugins at all are installed (neither JM plugins nor Zotero integration plugins). I'm flummoxed, no idea what might be the cause.

Frank

On Saturday, September 21, 2019 at 8:57:31 AM UTC+9, Frank Bennett wrote:

Just starting the work to adapt Jurism to the fx60 build. I've hit a snag in the first build:

-----

Could not read 'file:///media/storage/src/JM/zotero-standalone-build/staging/Jurism_linux-x86_64/extensions/zoteroOpenOfficeIntegra...@zotero.org/components/zoteroIntegration.xpt'.
-----

[Dan Stillman]

Both of those errors appear in the Zotero build as well. We'll look into them at some point, but I haven't noticed any ill effects. (Both LO and add-ons seem to be working fine.) You can ignore them.

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zotero-dev/dc069cef-01db-4717-bba5-f600c0651454%40googlegroups.com.

[Frank Bennett]

I see that type/field handling has been completely rebuilt in the fx60 branch. I have solid mappings for the Jurism extensions, so everything can be reconstructed, but it will take time. It's going to be hard to get an update done and tested in time for the new Mac OS. So a question ...

Are the new notarization requirements obligatory under the new Mac OS (that is, can they not be overridden in any way)? I've been releasing unsigned, with the intention of signing once there is a little cash flow in the project. If un-notarized apps can still be run, then I can postpone the release of this without impacting users. Otherwise, I'm going to have a bit of a crisis.

Frank

To unsubscribe from this group and stop receiving emails from it, send an email to zoter...@googlegroups.com.

[Dan Stillman]

On 9/20/19 10:26 PM, Frank Bennett wrote:
> Are the new notarization requirements obligatory under the new Mac OS
> (that is, can they not be overridden in any way)? I've been releasing
> unsigned, with the intention of signing once there is a little cash
> flow in the project. If un-notarized apps can still be run, then I can
> postpone the release of this without impacting users. Otherwise, I'm
> going to have a bit of a crisis.

Notarization is enforced by Gatekeeper as well, so it can be overridden
the same way. See "Open a developer-signed or notarized app" here:

https://support.apple.com/en-us/HT202491

(I also mentioned elsewhere in the thread that Apple relaxed the
notarization requirements until January 2020, but that was just to
temporarily enable notarization of apps that haven't yet been updated in
all the necessary ways — that's how Zotero 5.0.74 is already notarized.
But if you're not signing yet at all, that part is irrelevant.)

[Frank Bennett]

(Oh - notarized/non-notarized isn't relevant, is it. If zotero/master won't run on the new Mac OS, the shift to fx60 is mandatory, and the type/field refactoring bundled into it will have to be done. Ouch.)

[Dan Stillman]

On 9/20/19 10:34 PM, Frank Bennett wrote:
> (Oh - notarized/non-notarized isn't relevant, is it. If zotero/master
> won't run on the new Mac OS, the shift to fx60 is mandatory, and the
> type/field refactoring bundled into it will have to be done. Ouch.)

No, Zotero 5.0.74 (i.e., master) runs on Catalina now. There's a minor
font issue on non-Retina displays that we'd like to address, but
otherwise it should be fully functional.

[Frank Bennett]

Thanks for the furthers - this is all good to know, and quite a relief.

Frank

[Emiliano Heyns]

But I can still call Zotero.Prefs.get before those promises clear, right? I just will get undefined rather than the defaults?

[Dan Stillman]

Yes.

[Dan Stillman]

We're now planning to merge the fx60 branch into beta next week, so if you haven't yet updated your plugin, now would be the time to do so.

You can see an example of the (possibly incomplete) changes that were necessary for ZotFile in my PR here:

https://github.com/jlegewie/zotfile/pull/424/commits

That includes an example of using Zotero.platformMajorVersion to determine whether to use the new asynchronous FilePicker, so that you can roll out a new version that still works with 5.0.74. (The same would need to be done for iterateDirectory().)

Also, the dev channel builds weren't working on Windows, but that's now fixed, if anyone needs to test on Windows. You can download a ZIP build to avoid interfering with your normal installation:

https://www.zotero.org/download/client/dl?channel=dev&platform=win32-zip

Mac and Linux builds are here:

https://www.zotero.org/download/client/dl?channel=dev&platform=mac
https://www.zotero.org/download/client/dl?channel=dev&platform=linux

[Will S]

Just in case anyone else is affected by this -- I made the unwise decision to check Zotero.version instead of Zotero.platformMajorVersion for the conditionals where I wanted to support both the old and new Firefox runtimes. It seems that Zotero 5.0.75 was released recently with the old Firefox runtime and the release with the Firefox 60 runtime will be 5.0.76 or higher.

[Emiliano Heyns]

On Thursday, October 3, 2019 at 11:06:35 PM UTC+2, Dan Stillman wrote:

https://www.zotero.org/download/client/dl?channel=dev&platform=win32-zip

Mac and Linux builds are here:

https://www.zotero.org/download/client/dl?channel=dev&platform=mac
https://www.zotero.org/download/client/dl?channel=dev&platform=linux

The linux build seems to be missing:

curl -L 'https://www.zotero.org/download/client/dl?channel=dev&platform=linux' -o - | file -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
/dev/stdin: empty

[Dan Stillman]

On 10/9/19 3:20 PM, Emiliano Heyns wrote:

On Thursday, October 3, 2019 at 11:06:35 PM UTC+2, Dan Stillman wrote:

https://www.zotero.org/download/client/dl?channel=dev&platform=win32-zip

Mac and Linux builds are here:

https://www.zotero.org/download/client/dl?channel=dev&platform=mac
https://www.zotero.org/download/client/dl?channel=dev&platform=linux

The linux build seems to be missing:

Sorry, forgot the architecture:

https://www.zotero.org/download/client/dl?channel=dev&platform=linux-i686
https://www.zotero.org/download/client/dl?channel=dev&platform=linux-x86_64

[Emiliano Heyns]

Are there significant/incompatible changes to the database structure? I get a popup saying I should update my database should be upgraded.

[Emiliano Heyns]

When I import this RDF file: https://gist.github.com/retorquere/faf2265d5d17aa363bb15081419a7692#file-extra-field-rdf

I get this in the extra field with the current Zotero:

Citation Key: LiuHuaChun2018_HulianwangJinrongJianguan
biblatex{
  publisher: "Liu, \\chsf{刘华春}, Hua\\-chun",
  author: "Xu, \\chsf{}, Duo\\-qi"
}

but this when I import with dev:

company: 法律出版社
distributor: 法律出版社
institution: 法律出版社
label: 法律出版社
versionNumber: 1
Citation Key: LiuHuaChun2018_HulianwangJinrongJianguan
biblatex{
  publisher: "Liu, \\chsf{刘华春}, Hua\\-chun",
}


(this behavior is not particular to RDF import, it also happens with others, but this was easiest to replicate without BBT). I'm particularly surprised by "author" being stripped.

[Dan Stillman]

On 10/11/19 3:01 AM, Emiliano Heyns wrote:
> Are there significant/incompatible changes to the database structure?
> I get a popup saying I should update my database should be upgraded.

To clarify, the DB is upgraded automatically by the new code. You get
the prompt if you try to revert back to an older version.

The new code changes how types and fields are handled [1], so we had to
block clients that don't know how to handle the new schema stuff.


[1]
https://github.com/zotero/zotero/commit/4b60c6ca275ec69249b3ea81a669ae4823678d03

[Emiliano Heyns]

On Friday, October 11, 2019 at 8:59:16 PM UTC+2, Dan Stillman wrote:

On 10/11/19 3:01 AM, Emiliano Heyns wrote:
> Are there significant/incompatible changes to the database structure?
> I get a popup saying I should update my database should be upgraded.

To clarify, the DB is upgraded automatically by the new code. You get
the prompt if you try to revert back to an older version.

The new code changes how types and fields are handled [1], so we had to
block clients that don't know how to handle the new schema stuff.

What branch is dev being built from?

[Emiliano Heyns]

Similarly, when I import https://gist.github.com/454af00182034a9c8a05100c229bd2d6, the "event-place" in the "extra" field is changed to "place".

Will using "place" instead of "event-place" already work in the current release, so that I can adjust BBT to always expect/generate "place" rather than "event-place"?

[Emiliano Heyns]

Is there a list of fields that Zotero recognizes in "extra" other than the existing csl variables, and the mapping it uses to transform one into the other during import?

[Emiliano Heyns]

On Friday, October 11, 2019 at 8:59:16 PM UTC+2, Dan Stillman wrote:

On 10/11/19 3:01 AM, Emiliano Heyns wrote:
> Are there significant/incompatible changes to the database structure?
> I get a popup saying I should update my database should be upgraded.

To clarify, the DB is upgraded automatically by the new code. You get
the prompt if you try to revert back to an older version.

Right, I see. I don't see anything there that would affect BBT.

 

[Emiliano Heyns]

On Saturday, October 12, 2019 at 1:33:44 PM UTC+2, Emiliano Heyns wrote:

Is there a list of fields that Zotero recognizes in "extra" other than the existing csl variables, and the mapping it uses to transform one into the other during import?

Ah, it's CSL_TEXT_MAPPING. Do translators have access to Zotero.Utilities.Internal.extractExtraFields? Or will it be ran on itemToExportFormat before the items are handed to translators?

[Brenton Wiernik]

I had submitted a pull request a while back to parse more words (https://github.com/zotero/zotero/pull/1688), but Dan wanted to hold off until future field transfer was more clearly specified. I am surprised that `place` is getting parsed at all, considering that it's not a CSL variable.

[Emiliano Heyns]

On Monday, October 14, 2019 at 3:41:15 PM UTC+2, Brenton Wiernik wrote:

I had submitted a pull request a while back to parse more words (https://github.com/zotero/zotero/pull/1688), but Dan wanted to hold off until future field transfer was more clearly specified. I am surprised that `place` is getting parsed at all, considering that it's not a CSL variable.

It's not place being parsed (as far as I can tell), but event-place, which is being changed to place during import. This currently makes my tests fail, as I expect to see event-place there after import.

 

[Emiliano Heyns]

I've hacked around this in my test suite, but it's really unpretty. It'd be good to know whether this behavior will stay.

[Dan Stillman]

Sorry, these issues with Extra were due to a combination of bugs and unfinished code. I've reverted these changes in the latest dev build. Quoting my commit message:

 Don't store unknown/invalid fields in Extra in non-strict mode

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. 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.

[Dan Stillman]

We've rolled out the new Firefox 60 base on the beta channel. If you
have a plugin that you haven't yet updated, you'll want to do that now,
or else your plugin will be broken for Zotero beta testers.

Just a reminder that 'dev' channel builds will no longer be updated, so
be sure to switch to the beta channel to continue testing.

Beta builds are available here: https://www.zotero.org/support/dev_builds

Let us know if you run into any additional problems with the new code.

[Brenton Wiernik]

Two things:

First, minor display bug in the current beta. The divider line between Add-ons and Developer disappears if you hover over Developer or another menu item that makes a popup menu appear.

Second, I've been doing minor maintenance releases of Zotero QuickLook, but I haven't dived much into its actual functionality. In the current beta, it no longer works. When I try to open QuickLook by pressing Space, I get the error that "domWindowUtils.sendKeyEvent is not a function" in "xpcom/itemTreeView.js". Has this function just changed names so that there is potentially a straightforward fix here?

[Emiliano Heyns]

 I've removed my workarounds, and my tests pass on the beta, so I seem set.

[Dan Stillman]

On 10/22/19 8:29 PM, Brenton Wiernik wrote:
> Second, I've been doing minor maintenance releases of Zotero
> QuickLook, but I haven't dived much into its actual functionality. In
> the current beta, it no longer works. When I try to open QuickLook by
> pressing Space, I get the error that "domWindowUtils.sendKeyEvent is
> not a function" in "xpcom/itemTreeView.js". Has this function just
> changed names so that there is potentially a straightforward fix here?

I've fixed this in the latest beta — thanks. (Keyboard handling in the
items list, including assignment of colored tags, was broken in general.)

QuickLook will still need to be updated for Fx60, though. It's logging a
`for each(` syntax error, so it won't load at all currently. I didn't
look into whether there are other issues.

[Dan Stillman]

On 10/22/19 8:29 PM, Brenton Wiernik wrote:

> First, minor display bug in the current beta. The divider line between
> Add-ons and Developer disappears if you hover over Developer or
> another menu item that makes a popup menu appear.

Can you share a couple screenshots for this? There shouldn't ever be a
divider between Add-ons and Developer.

[Brenton Wiernik]

Oh, okay. It appears that it is introduced when Zutilo is enabled.

See below:

[Frank Bennett]

Jurism question here.

Now that fx60 is in master, I'm starting again (time permitting) to work on merging those changes.

First question: How are item type IDs / creator type IDs / field IDs now set in master? The mappings have disappeared from system.sql, and I can't seem to find a human-readable source file elsewhere.

FB

[Dan Stillman]

On 11/13/19 12:46 AM, Frank Bennett wrote:
> Jurism question here.
>
> Now that fx60 is in master, I'm starting again (time permitting) to
> work on merging those changes.
>
> First question: How are item type IDs / creator type IDs / field IDs
> now set in master? The mappings have disappeared from system.sql, and
> I can't seem to find a human-readable source file elsewhere.

`git submodule update --init` and look in resource/schema/global/.

Fields are read in from schema.json and stored in the usual tables.

Relevant commit is here:
https://github.com/zotero/zotero/commit/4b60c6ca275ec69249b3ea81a669ae4823678d03

Let me know if you have other questions.

[Frank Bennett]

Ah, right, I get it now. The schema is a subproject, and I hadn't
pulled it yet. All clear so far.

FB

> --
> You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/zotero-dev/0100016e6356e324-02ddd231-0c8e-4ae7-ac96-b47989d80d17-000000%40email.amazonses.com.

[Emiliano Heyns]

On Wednesday, November 13, 2019 at 6:57:50 AM UTC+1, Dan Stillman wrote:

`git submodule update --init` and look in resource/schema/global/.

Fields are read in from schema.json and stored in the usual tables.

Relevant commit is here:
https://github.com/zotero/zotero/commit/4b60c6ca275ec69249b3ea81a669ae4823678d03

Let me know if you have other questions.

What does "meta" mean in that schema.json?

[Dan Stillman]

On 11/13/19 2:28 AM, Emiliano Heyns wrote:
> What does "meta" mean in that schema.json?

https://github.com/zotero/zotero-schema

"Additional field info, such as which fields are date fields"

[Emiliano Heyns]

Right, sorry about that

[Frank Bennett]

One more question ...

The schema.json provides field and type names. Are there static
assignments of the field and type IDs, or are those meant to be
dynamically assigned in the new code?

On Wed, Nov 13, 2019 at 2:57 PM Dan Stillman <dsti...@zotero.org> wrote:
>

[Dan Stillman]

On 11/13/19 2:44 AM, Frank Bennett wrote:
> The schema.json provides field and type names. Are there static
> assignments of the field and type IDs, or are those meant to be
> dynamically assigned in the new code?

They're not static. There's a warning about that for third-party code in
the commit message I linked to, and I mentioned it in an earlier message
in this thread [1].


[1] https://groups.google.com/d/msg/zotero-dev/a1IPUJ2m_3s/TLaReqkuAwAJ

[Frank Bennett]

Partially answering my own question below, but to confirm ...

From chrome/content/zotero/xpcom/schema.js and chrome/content/zotero/xpcom/id.js, it looks as though IDs are drawn from the existing entries in the database, unless the field name is a new one. In the latter case, the maximum ID for the category (field, itemType, creatorType etc) is incremented by 1, and assigned to the new field.

Is that an accurate description?

On Wednesday, November 13, 2019 at 4:44:52 PM UTC+9, Frank Bennett wrote:

One more question ...

The schema.json provides field and type names. Are there static
assignments of the field and type IDs, or are those meant to be
dynamically assigned in the new code?


On Wed, Nov 13, 2019 at 2:57 PM Dan Stillman <dsti...@zotero.org> wrote:
>
> On 11/13/19 12:46 AM, Frank Bennett wrote:
> > Jurism question here.
> >
> > Now that fx60 is in master, I'm starting again (time permitting) to
> > work on merging those changes.
> >
> > First question: How are item type IDs / creator type IDs / field IDs
> > now set in master? The mappings have disappeared from system.sql, and
> > I can't seem to find a human-readable source file elsewhere.
>
> `git submodule update --init` and look in resource/schema/global/.
>
> Fields are read in from schema.json and stored in the usual tables.
>
> Relevant commit is here:
> https://github.com/zotero/zotero/commit/4b60c6ca275ec69249b3ea81a669ae4823678d03
>
> Let me know if you have other questions.
>
> --
> You received this message because you are subscribed to the Google Groups "zotero-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+unsubscribe@googlegroups.com.

[Dan Stillman]

On 11/13/19 3:14 AM, Frank Bennett wrote:
> Partially answering my own question below, but to confirm ...
>
> From chrome/content/zotero/xpcom/schema.js and
> chrome/content/zotero/xpcom/id.js, it looks as though IDs are drawn
> from the existing entries in the database, unless the field name is a
> new one. In the latter case, the maximum ID for the category (field,
> itemType, creatorType etc) is incremented by 1, and assigned to the
> new field.
>
> Is that an accurate description?

Yes, but you shouldn't make any assumptions about the ids that get
assigned. You should always use Zotero.ItemTypes.getID(…) and the like.

[Frank Bennett]

Yes, absolutely. I just wanted to be sure I understood how the code works, before setting up to patch in additional fields for Jurism. Thanks for the pointers, and apologies for not reading up more fully before posting.

FB

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zotero-dev/0100016e63e220db-24938356-5b6b-4ccb-8973-cc6c64a7d20e-000000%40email.amazonses.com.

[Frank Bennett]

I've gotten to the point of running tests against a draft Jurism update, but I've hit a little snag. An attempt to invoke the "normalize" command from utilities_internal.js throws an error:

*****

    ✖ [FAIL] should copy HTML and text citations to the clipboard

      Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITransferable.getTransferData] at

getDataForFlavor@resource://zotero-unit-tests/fileInterfaceTest.js:116:7

        @resource://zotero-unit-tests/fileInterfaceTest.js:133:17

Possibly unhandled rejection:

Components.classes['@mozilla.org/intl/unicodenormalizer;1'] is undefined

*****

This is an optional call that I added to citeproc.js quite a long time ago, and if Zotero normalizes Unicode separately, I'll just remove it. Out of curiosity though, is the "normalize" function used by current Zotero? (And if so, are there steps needed to wake it up?)

[Emiliano Heyns]

Isn't string normalization just built into the String prototype? That's how I've always used it (assuming you're talking about https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize)

[Dan Stillman]

On 11/26/19 10:41 PM, Emiliano Heyns wrote:
> Isn't string normalization just built into the String prototype? That's how I've always used it (assuming you're talking about https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize)
>

Utilities.Internal.normalize() predates String.prototype.normalize(),
but the latter has been available since 2014, and we just use that
everywhere. I'll remove Utilities.Internal.normalize().

[Brenton Wiernik]

Dan, thanks for your help on QuickLook. I’m wondering if you could also help me decipher this error I’m getting testing it on Windows: https://github.com/mronkko/ZoteroQuickLook/pull/21#issuecomment-560752609

[George MacKerron]

Dan, I develop a Zotero extension, Zot2Bib: https://github.com/jawj/Zot2Bib/

On current Zotero (5.0.80) this is broken, with the error message:

[JavaScript Error: "ReferenceError: Zot2Bib is not defined" {file: "chrome://zotero/content/standalone/standalone.xul" line: 1}] onpopuphidden@chrome://zotero/content/standalone/standalone.xul:1:1

Zot2Bib is the single symbol exported by the extension's main code module: https://github.com/jawj/Zot2Bib/blob/master/modules/zot2bib.jsm

I'm no XUL expert, and I'm not really sure where to start with this. Would you be able to give a few pointers?

Many thanks,

George

On Wednesday, 28 August 2019 11:44:15 UTC+1, Dan Stillman wrote:

We'll soon be updating Zotero's underlying platform from Firefox 52 ESR
to Firefox 60 ESR.

This allows us to meet the new app notarization requirements in macOS
Catalina [1], coming in September, and it also provides us with all the
improvements that came between Firefox 52 and 60, including the
performance improvements in Firefox 57 (though we haven't yet tested how
much those affect us).

Unfortunately, this upgrade will require most Zotero plugins to be
updated, though Zotero's own updates should serve as a fairly
comprehensive roadmap.

You can see a list of all the Zotero changes here:

https://github.com/zotero/zotero/compare/master...fx60

Build changes (probably only relevant to Jurism) are here:

https://github.com/zotero/zotero-standalone-build/compare/master...fx60

Most plugins hopefully won't encounter most of this, but here are some
highlights that may come up:

- Old-style Mozilla shorthand function definitions should be replaced
with arrow functions
(https://github.com/zotero/zotero/commit/9ca1014f5bc90b6edabb5f04b3f73df09fdb246a)

- `nsILocalFile` should be changed to `nsIFile` or replaced with strings
paths or `Zotero.File.pathToFile()`
(https://github.com/zotero/zotero/commit/433794916a493d68cc793fd8fa577e2db5ad3efe)

- `nsIFilePicker::show()` was removed in favor of `.open(callback)`, but
we added a replacement `FilePicker` module with an `await fp.show()`that
should be used instead
(https://github.com/zotero/zotero/commit/6f965251ed8eea160f95edaa8274c1bd786fafdc)

- `nsIURI` is now immutable, so you have to use
`uri.mutate().setFilePath(uri.filePath + '/foo').finalize()` or similar
to make a new URI with modifications
(https://github.com/zotero/zotero/commit/61e976bd3aec95b73cd993e685adfa897ab3784f)

- `nsIURI::path` is now `nsIURI::pathQueryRef`

- `prefwindow` and related XBL bindings were removed, but we've restored
them for now. If you have a preferences window, you need to include an
additional CSS file.
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- The `Zotero.File.iterateDirectory()` signature changed
(https://github.com/zotero/zotero/commit/79276edd145cb2705fc0acc418e9abb61f63da08)

- XMLHttpRequest is now just `new XMLHttpRequest()` even in XPCOM
(https://github.com/zotero/zotero/commit/6fd879fc16552b3a16a5cbad0a74cb19baf15a35)

We've put up test builds on a dev channel that you can use to test and
update your plugins:

https://download.zotero.org/client/dev/5.0.75-dev.1%2B2a613258e/Zotero-5.0.75-dev.1%2B2a613258e.dmg
https://download.zotero.org/client/dev/5.0.75-dev.1%2B2a613258e/Zotero-5.0.75-dev.1%2B2a613258e_linux-x86_64.tar.bz2
https://download.zotero.org/client/dev/5.0.75-dev.1%2B2a613258e/Zotero-5.0.75-dev.1%2B2a613258e_win32.zip

(This channel won't be active most of the time, so you shouldn't expect
to stay on it after this development cycle.)

We need to push this branch to the beta channel at the end of next week
so that it gets sufficient testing, so you'll need to update your
plugins by then for them to continue working for beta users. Catalina
will probably come out September 23rd, so we need to have at least the
Mac version in production by then.

Sorry for the late notice here. The current version of Zotero works
essentially fine on Catalina, and we weren't anticipating the
notarization changes to require a platform upgrade, but that ended up
being the least-annoying option. We're happy to work with plugin
developers over the next couple weeks to make sure plugins are updated
in time, and other plugin developers may be willing to pitch in as well,
so please post here if you don't think you'll be able to finish on time.
Also feel free to post here or CC me on GitHub if anything is unclear
from the Zotero commits or if you run into other incompatibilities.

- Dan


[1]
https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

[Dan Stillman]

On 12/5/19 9:18 AM, George MacKerron wrote:
> Dan, I develop a Zotero extension, Zot2Bib:
> https://github.com/jawj/Zot2Bib/
>
> On current Zotero (5.0.80) this is broken, with the error message:
> [JavaScript Error: "ReferenceError: Zot2Bib is not defined" {file:
> "chrome://zotero/content/standalone/standalone.xul" line: 1}]
> onpopuphidden@chrome://zotero/content/standalone/standalone.xul:1:1
>
> Zot2Bib is the single symbol exported by the extension's main code
> module: https://github.com/jawj/Zot2Bib/blob/master/modules/zot2bib.jsm
>
> I'm no XUL expert, and I'm not really sure where to start with this.
> Would you be able to give a few pointers?

Where are you looking for errors? If I load the master branch of your
extension via an extension proxy file [1] (which is how you want to be
working on this), there are clear errors in the Zotero Error Console —
first about octal literals (0644 → 0o644), then once that's fixed about
an assignment to an undeclared Zot2Bib variable (add var), then about
another undeclared variable, and so on.

Happy to answer questions on any errors you're unsure about, but you'll
want to start by going through those one by one.


[1]
https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Setting_up_extension_development_environment#Firefox_extension_proxy_file
but with the Zotero profile directory instead

[George MacKerron]

Thanks Dan. I had spotted the Debug Output log but not the developer Error Console, so that's a good start! And I have finally got the proxy file to work by creating a new profile.

I fixed the errors you noted, changed nsILocalFile to nsIFile in a couple of places, and replaced a file picker show() with open(). The extension now mostly works.

I have a few remaining problems, though. The preferences no longer seem to automatically sync themselves with their corresponding UI checkboxes. And the fonts in the preferences box have become strangely big.

I also get these log entries at load — not sure if they're relevant, though the second one seems suggestive:

[JavaScript Warning: "unreachable code after return statement" {file: "resource://zotero/loader.jsm -> resource://zotero/bluebird/util.js" line: 201 column: 4 source: "    eval(obj);
"}]

[JavaScript Error: "addon.getResourceURI is not a function" {file: "chrome://zotero/content/xpcom/prefs.js" line: 390}]

Any ideas?

Thanks,

George

[Emiliano Heyns]

I'm suddenly seeing a spate of reports where BBT fails to initialize because Zotero.Schema.schemaUpdatePromise does not resolve. I have in the latest built postponed everything BBT does to start up to after Zotero.Schema.schemaUpdatePromise resolves to make sure I'm not messing up anything during startup (I used to do a part of my init between uiReadyPromise and schemaUpdatePromise), but I'm still getting reports in. I cannot, unfortunately, reproduce this myself. I've added a timer during startup that just periodically reports whether Zotero.Schema.schemaUpdatePromise is still pending, every half second, and I see no errors in the logs I get. The tail of the most current log looks like

(3)(+0000003): Getting contents of /Users/dae/Documents/Zotero/styles/apa.csl
(3)(+0000004): Getting contents of /Users/dae/Documents/Zotero/styles/chicago-author-date.csl
(3)(+0000003): Getting contents of /Users/dae/Documents/Zotero/styles/modern-language-association.csl
(3)(+0000001): Getting contents of /Users/dae/Documents/Zotero/styles/american-sociological-association.csl
(3)(+0000001): Getting contents of /Users/dae/Documents/Zotero/styles/chicago-note-bibliography.csl
(3)(+0000004): Cached 17 styles in 38 ms
(3)(+0000000): HTTP GET chrome://zotero/content/locale/csl/locales.json
(3)(+0000001): HTTP GET chrome://zotero/content/locale/csl/locales.json succeeded with 200
(3)(+0000000): HTTP GET resource://zotero/schema/renamed-styles.json
(3)(+0000001): HTTP GET resource://zotero/schema/renamed-styles.json succeeded with 200
(3)(+0000002): HTTP GET resource://zotero/schema/repotime.txt
(3)(+0000001): HTTP GET resource://zotero/schema/repotime.txt succeeded with 200
(4)(+0000002): SELECT version FROM version WHERE schema='delete'
(3)(+0000000): Getting contents of input stream
(4)(+0000001): SELECT version FROM version WHERE schema=? ['styles']
(3)(+0000001): Installed styles are up-to-date with XPI
(3)(+0000001): {better-bibtex} +136 trace: Zotero.Schema.updateBundledFiles end, Zotero.Schema.schemaUpdatePromise.isPending = true
(3)(+0000000): {better-bibtex} +0 trace: Zotero.Schema.updateFromRepository start, Zotero.Schema.schemaUpdatePromise.isPending = true
(3)(+0000000): HTTP GET https://api.zotero.org/retractions/list
(3)(+0000274): HTTP GET https://api.zotero.org/retractions/list succeeded with 200
(3)(+0000069): HTTP POST "["d66546","dc9b8a","d6123e","de9feb","ddadec","d794b1","d6b545","d51b5e","d09b94","d58587","dec771","p26000","d47ab3","d368df","d6369b","d0605c","d18616","de2dcc","d7a297","d05c54","d37c80","da9dba","de47a3","dde161","d3312e","p27439","ddec9c","de1235","d51969","dab728","p30110","d1343b","d871d0","de2759","db043c","d7b638","d8b2c7","de4eeb"]" to https://api.zotero.org/retractions/search
(3)(+0000025): {better-bibtex} +367 Startup progress: Zotero locks after 7881: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000080): HTTP POST https://api.zotero.org/retractions/search succeeded with 200
(3)(+0000000): Retrieved 39 possible matches
(4)(+0000002): REPLACE INTO retractedItems (itemID, data) VALUES (?, ?) [12012, '{"date":"2019-08-05","doi":"10.1016/j.cub.2019.07.030","pmid":31386841,"reasons":["Error in Analyses","Error in Results and/or Conclusions"],"urls":[]}']
(3)(+0000003): Refreshing collections pane
(4)(+0000003): SELECT savedSearchID FROM savedSearches WHERE libraryID=? [1]
(4)(+0000013): SELECT itemID FROM items JOIN deletedItems USING (itemID) WHERE libraryID=? [1]
(4)(+0000003): SELECT savedSearchID FROM savedSearches WHERE libraryID=? [3]
(4)(+0000001): SELECT itemID FROM items JOIN deletedItems USING (itemID) WHERE libraryID=? [3]
(4)(+0000001): SELECT savedSearchID FROM savedSearches WHERE libraryID=? [4]
(4)(+0000001): SELECT itemID FROM items JOIN deletedItems USING (itemID) WHERE libraryID=? [4]
(3)(+0000002): Collection selection hasn't changed
(3)(+0000001): Notifier.trigger('refresh', 'item', [12012]) called [observers: 13]
(3)(+0000392): {better-bibtex} +502 Startup progress: Zotero locks after 8382: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000499): {better-bibtex} +500 Startup progress: Zotero locks after 8883: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000504): {better-bibtex} +503 Startup progress: Zotero locks after 9386: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000131): {better-bibtex} +131 trace: Zotero.Schema.updateBundledFiles after 2 seconds, Zotero.Schema.schemaUpdatePromise.isPending = true
(3)(+0000373): {better-bibtex} +374 Startup progress: Zotero locks after 9891: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000505): {better-bibtex} +505 Startup progress: Zotero locks after 10395: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000505): {better-bibtex} +505 Startup progress: Zotero locks after 10901: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000504): {better-bibtex} +504 Startup progress: Zotero locks after 11405: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000505): {better-bibtex} +504 Startup progress: Zotero locks after 11909: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(4)(+0000438): SELECT COUNT(*) FROM settings WHERE setting='mImport' AND key='cleanup'
(3)(+0000065): {better-bibtex} +504 Startup progress: Zotero locks after 12413: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending
(3)(+0000504): {better-bibtex} +503 Startup progress: Zotero locks after 12916: Zotero.uiReadyPromise: resolved , Zotero.Schema.schemaUpdatePromise: pending

and after that no other activity than my timer reporting Zotero.Schema.schemaUpdatePromise still pending.

I know this is BBT and therefore some suspicion is warranted, but I have not seen anything like this before. I can see that Zotero.Schema.updateBundledFiles is being called and finishes, then immediately after updateFromRepository is called as expected but I don't see that finishing... but also no error, or any logging at all actually, even a full minute later. When I have the user turn off automaticScraperUpdates, the call to updateFromRepository between uiReadyPromise and schemaUpdatePromise is skipped, and BBT starts up as usual.

Does anything that's relevant to BBT happen between Zotero.uiReadyPromise and Zotero.Schema.schemaUpdatePromise resolving BTW? Looking at the code I only see a call to updateFromRepository, and that in turn just fetches styles, scrapers and retractions. Can I just wait for Zotero.uiReadyPromise?