Zotero 5 freezes on startup, when an unsuccessful save from Chrome connector was issued before.
I recently discovered that (my) Zotero 5 hangs soon after start in the state of loading entries and tags (emty lists with temporary message shown).
Then I figured out that I was trying to (unsuccessfully) save an entry from Chrome. Before of that I was notified by the Plugin, that Zotero is not running.
When I started Zotero I had the issue above. After kicking the Zotero Prozess via Alt-Dock Menu, I restarted Zotero and it comes up fine and the entry denied before was there.
I use Zotero 5.0.28, MacOSX 10.11.6, Chrome 62.0.3202.94, Zotero Connector 5.0.27
Then I figured out that I was trying to (unsuccessfully) save an entry from Chrome. Before of that I was notified by the Plugin, that Zotero is not running.
When I started Zotero I had the issue above. After kicking the Zotero Prozess via Alt-Dock Menu, I restarted Zotero and it comes up fine and the entry denied before was there.
I use Zotero 5.0.28, MacOSX 10.11.6, Chrome 62.0.3202.94, Zotero Connector 5.0.27
I did let the library load until my "feeling" and the Finder Dock menu told me "it is not responding" and I restarted the app.
I waited 30 seconds and up to a minute. About 3-5 times longer than a usual successful "vanilla" load under 5.0.28, 5.0.28 needs.
A normal load of my ~30GB WebDAV and 25 groups takes currently usually 12 to 15 seconds on the fast 4 core MBPro i7 which is OK for me. And it works in 5 even on 10 years an old iMac and MacMini DualCore 2.6 with 4 and 8GB RAM.
Vanilla load means: No Zotero Connector action issued after a successful loaded Zotero 5 was closed properly.
The message text with 5.0.28 in German was "Lade Tags..." and "Lade Einträge..." which means "loading tags..." and "loadings entries...".
The delay/hung is currently not reproducable with 5.0.29.
So far and thanks for the response.
By the way: I call Zotero a "robust" application with almost no serious lost of data since 8 years. Congratulation!
I would rephrase it like this:
When a save from connector was instantiated while Zotero is not running, a message popped up in the browser, that Zotero is not available (not running).
The dialog offers an option to close the attempt to save or start a retry.
This implicitly suggested to start Zotero manually ( ;-) Hey, lets automate this, ;-( but security will spoil that...)...
During these startups I recognized the above "hang like" issue.
When I started Zotero during this dialog was open, (and maybe a thread still working that pulles messages to Zotero) Zotero`s startup hanged up.
Maybe there is a design flaw that expects a certain response during response that is eaten up or blocked over by a higher priority by the external save request.
If I killed Zotero from commandline ord via Dock alt-Quit , closed the browser, and started Zotero 5 (formerly known as Standalone) again – it opened now with no serious timing difference to the behaviour without (my) issue. Maybe the command queue is then flushed.
off topic
Some anecdote on (application)-design
I admired Adobe 20 years ago (not now) when in Illustrator (version 5 or so) they always flushed the time consuming display routine every time the user pressed a hotkey action and just displayed the final result of the executed command chain. This was after they rewrote their display engine called Topaz from scratch. Freehand instead was serious candidate for a heavy crash after pressing some hotkeys after each other (known as "n-key rollover" for early keyboard encoder hardware designers).
In the last years they not even managed to stardardize the letter case between library calls and the filenames of their libraries, resulting in the inability to install the creative suite on a drive with filename case sensitivity. So you life can get cumbersome if you have no idea what other people do or that they use unicode letters.
For the Zotero Team I have no doubts that they are doing a wonderful job. I really like the responsiveness in the forum when I issue some feedback.