Closed VorpalBlade closed 4 years ago
It looks like you did not upload an debug report. The debug report is important; it gives @retorquere your current BBT settings and a copy of the problematic reference as a test case so he can best replicate your problem. Without it, @retorquere is effectively blind. Debug reports are useful for both bug analysis and enhancement requests; in the case of export enhancements, I need the copy of the references you have in mind.
If your issue relates to how BBT behaves around a specific reference(s), such as citekey generation or export, select at least one of the problematic reference(s), right-click it, and submit an BBT debug report from that popup menu. If the problem is with export, please do include a sample of what you see exported, and what you expected to see exported for these references.
If the issue does not relate to references and is of a more general nature, generate an debug report by restarting Zotero with debugging enabled (Help -> Debug Output Logging -> Restart with logging enabled), reproducing your problem, and selecting "Send Better BibTeX debug report..." from the help menu.
Once done, you will see a debug ID in red. Please post that debug id in the issue here.
Thank you!
As I stated: The debug report doesn't actually work! Thus I can't attach it. Hopefully you will look at this bug regardless.
Alas downgrading doesn't work. I see the same issue with 5.0.77. (Even when restoring older database files). This has completely broken my ability to work on my report. I will have to restore everything from a backup from last week and then try to manually re-add any newly added papers since then.
Aha, downgrading Better BibLaTeX to v5.1.164 fixes it. Both v5.1.165 or v5.1.166 exhibit the issue though. In this older version the error report functionality also works, but that is of no use to you I assume, since this version works.
As I stated: The debug report doesn't actually work! Thus I can't attach it. Hopefully you will look at this bug regardless.
Yeah don't worry about it, that's a bot that watches the tracker.
Can you start Zotero using
zotero -ZoteroDebugText > ~/BBT.log
there will be a log in ~/BBT.log
, if you can put that in a gist and post the link here I'll get right on it.
Crashes like this:
It looks like the crashing error is this:
TypeError: key_manager_1.KeyManager is undefined
TypeError: key_manager_1.KeyManager is undefined
init@chrome://zotero-better-bibtex/content/BetterBibTeX.ItemPane.js:29:21
./ItemPane.ts/</<@chrome://zotero-better-bibtex/content/BetterBibTeX.ItemPane.js:53:9
From previous event:
ZoteroPane</this.itemSelected@chrome://zotero/content/zoteroPane.js:1321:12
onselect@chrome://zotero/content/standalone/standalone.xul:1:1
onxblmousedown@chrome://global/content/bindings/tree.xml:1145:14
The Invalid field 'citekey' for base field
one is from the tree's getCellText()
, presumably for the citation key column, but that wouldn't be fatal.
Here is my log: BBT.log
@VorpalBlade can you go into Zotero advanced prefs /config editor and look what extensions.zotero.translators.better-bibtex.testing
is set to?
It looks like the crashing error is this:
TypeError: key_manager_1.KeyManager is undefined TypeError: key_manager_1.KeyManager is undefined init@chrome://zotero-better-bibtex/content/BetterBibTeX.ItemPane.js:29:21 ./ItemPane.ts/</<@chrome://zotero-better-bibtex/content/BetterBibTeX.ItemPane.js:53:9 From previous event: ZoteroPane</this.itemSelected@chrome://zotero/content/zoteroPane.js:1321:12 onselect@chrome://zotero/content/standalone/standalone.xul:1:1 onxblmousedown@chrome://global/content/bindings/tree.xml:1145:14
The
Invalid field 'citekey' for base field
one is from the tree'sgetCellText()
, presumably for the citation key column, but that wouldn't be fatal.
The weird thing is I patch getCellText
to look for that ID and return either an empty string (when BBT is not fully initialized) or the citekey (when it is). The call should never reach the actual getCellText
, which makes me think something errored out much earlier in BBT, causing the monkey-patch never to have happened, and then you'd see this.
Another weird thing is that I'm running my full test suite every night on both release and beta of Zotero, and even when I run my test suite now on 5.0.78, I can't yet reproduce it.
:robot: this is your friendly neighborhood build bot announcing test build 5.1.166.5262 ("late setting of default prefs")
Install in Zotero by downloading test build 5.1.166.5262, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".
I have attached a new log file from this version: BBT.log
test build 5.1.166.5262 does not resolve the issue for me :(
It should also be noted that Zotero version did not seem to matter. I have downgraded and upgraded it. It appears that Better BibTex and Zotero happened to update at the same time. However the dialog only said Zotero was updating, thus I incorrectly assumed that was the only thing that had changed. Thus the only relevant variable seems to be that version 165 and newer fail on my system.
This is one of the dangers of automatic quiet updates.
I have the same issue. Anyone else had the problem of Zotero looking like this after removing BBT?
I have it reproducible. On it.
@mgarke that's unfortunately what happens if BBT isn't uninstalled cleanly. With BBT running, Zotero remembers it in the column config, if the column config has unexpected items (and with BBT gone, the config for its column is unexpected), this is what Zotero does. I can't do anything about that, sorry.
:robot: this is your friendly neighborhood build bot announcing test build 5.1.166.5263 ("old-style patch")
Install in Zotero by downloading test build 5.1.166.5263, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".
Just going to quickly chime in - I have had the same issue as @VorpalBlade and the latest test build installed fine for me without crashing. Will test further and report back. Thanks for the quick reply @retorquere!
@daemuth just to verify -- it is 5263 that fixes it for you?
test build 5.1.166.5263 still leads to same error :(
[JavaScript Error: "'item' must be a Zotero.Item" {file: "chrome://zotero/content/bindings/itembox.xml" line: 106}]
[JavaScript Error: "'item' must be a Zotero.Item" {file: "chrome://zotero/content/bindings/itembox.xml" line: 106}]
version => 5.0.78, platform => MacIntel, oscpu => Intel Mac OS X 10.12, locale => en-US, appName => Zotero, appVersion => 5.0.78, extensions => ZotFile (5.0.14, extension), Zotero Word for Mac Integration (5.0.24.SA.5.0.78, extension), Zotero LibreOffice Integration (5.0.20.SA.5.0.78, extension), Better BibTex for Zotero (5.1.166.5263, extension), Shockwave Flash (32.0.0.293, plugin, disabled)
@daemuth just to verify -- it is 5263 that fixes it for you?
Correct!
@tobiaskramer this is most likely collateral damage. Can you cmd-Q zotero and run
/Applications/Zotero.app/Contents/MacOS/zotero -ZoteroDebugText > ~/Downloads/BBT.txt
in a terminal window, then put the log in ~/Downloads/BBT.txt
in a gist and post the link here?
@retorquere: If you haven't yet, can you revert update.rdf and remove/rename the 165/166 XPIs while you're troubleshooting this so that people who haven't yet received the update stay on 5.1.164?
@retorquere: If you haven't yet, can you revert update.rdf and remove/rename the 165/166 XPIs while you're troubleshooting this so that people who haven't yet received the update stay on 5.1.164?
Good point -- done
ok, after restarting several times (since I had to enable/disable the plugin) test build 5.1.166.5263 works! so there was some cruft around. (At least it doesn't crash, have to check if the generated bib files are fine). Thanks for your efforts. Hope there is a way to avoid such a situation in the future (maybe delay major simultaneous automatic updates, or warn the users who prefer stability). Thanks again!
@tobiaskramer BBT is tested on the latest beta every night. The issue is that testing
preference -- I'm looking for a way to remove it, but 5263 removes the check for it. I don't know how it got set in your profile -- it is never set by BBT itself, just read.
@mgarke can you give 5263 a spin? If that resolves it for you too (as I expect it should), I'm cutting a new release.
I had this issue and finally got 5263 to work after deleting ~/Library/Caches/Zotero (on mac).
@trondbn I don't know exactly what's cached there, but it's disconcerting that you had to remove it. I should hope that a new version would invalidate any caches programs might have held, but 5263 is such a new version. That would mean it's code being cached, not just data, because the code in 5263 no longer checks for testing
.
@retorquere 5263 works well for me (without removing caches). thank you!!
Yes, this new test build (5.1.166.5263) fixes the issue for me too.
I did not have to delete any cache (on Linux)
Ugh, I understand now why this happened; it's an artifact of the testing obviously, but it
undefined
in productionbut since defaults/prefs.js loading has changed, testing
now gets set to false
explicitly by BBT. There's an overly zealous check that testing
doesn't get reset to false
, and this was now triggering. This fully explains why you guys are seeing it, and my tests not. That check is now gone.
Release tests take longer than per-commit tests, so a new version should be out in about 30 minutes. Again, apologies for the disruption.
Thanks for the quick fix. It's more than unusual to get that fast developer feedback 👍
Oh, by the way: After updating to the latest release on my mac, I didn't have to manually remove any caches either for everything to work properly again 😃
Very welcome. I don't like to start my day off with causing such mayhem, but I'm glad I could get to it quickly with everyone helping out with logs in this thread. Super thanks people. New release is out.
Oh, by the way: After updating to the latest release on my mac, I didn't have to manually remove any caches either for everything to work properly again 😃
That's a major relief. I'm working on permanently removing the preference to remove even the chance of it reoccurring.
@JonasDralle it'd be a relief for me to know whether 5362/5.1.167 (same thing) fixes the problem for you too.
Hope there is a way to avoid such a situation in the future (maybe delay major simultaneous automatic updates, or warn the users who prefer stability). Thanks again!
I try to do this by running my full test suite against both zotero release and zotero beta once every night. This wasn't an incompatibility issue between them, it was actually a flaw in my test setup whose behavior leaked into the production behavior.
BBT tests starts an actual Zotero (release/beta) with an actual BBT build. On every commit I make, about 90% of my test suite is ran, excluding some tests that take a long time to complete, and only against Zotero release. Every night, and every release build, runs the full suite, against both Zotero release and beta. Incompatibilities with new versions should be caught in no more than 24 hours, and at least before I can even make a release: all releases go through my CI setup, and consequently, if even a single test fails, a new version will not be published; this is why sometimes the version skips a few, because I cannot re-release such a failed build/test.
I am deeply sorry for the mayhem I caused, but I think for a one-man spare-time project, I've gone the extra mile in terms of diligence and turnaround. I don't see what I could realistically do more.
It seems that I'm having the same issue today:
[JavaScript Error: "key_manager_1.KeyManager is undefined" {file: "chrome://zotero-better-bibtex/content/BetterBibTeX.ItemPane.js" line: 29}]
[JavaScript Error: "key_manager_1.KeyManager is undefined" {file: "chrome://zotero-better-bibtex/content/BetterBibTeX.ItemPane.js" line: 29}]
version => 5.0.78, platform => Linux x86_64, oscpu => Linux x86_64, locale => en-US, appName => Zotero, appVersion => 5.0.78, extensions => ZotFile (5.0.14, extension), Zotero DOI Manager (1.3.9, extension), Zotero Scholar Citations (2.0.4, extension), Markdown Here (2.13.4, extension), Zutilo Utility for Zotero (3.3.0, extension), Zotero Report Customizer (5.0.32, extension), Zotero Date From Last Modified (0.0.12, extension), Better BibTex for Zotero (5.1.166, extension), Zotero LibreOffice Integration (5.0.20.SA.5.0.78, extension), Shockwave Flash (32.0.0.293, plugin)
(5)(+0067662): POST /connector/ping HTTP/1.1 Host: 127.0.0.1:23119 Connection: keep-alive Content-Length: 2 X-Zotero-Version: 5.0.60 Origin: chrome-extension://ekhagklcjbdpajgpjgmbionohlpdbjgc X-Zotero-Connector-API-Version: 2 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 DNT: 1 Content-Type: application/json Accept: */* Sec-Fetch-Site: cross-site Sec-Fetch-Mode: cors Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9
(5)(+0000002): HTTP/1.0 200 OK X-Zotero-Version: 5.0.78 X-Zotero-Connector-API-Version: 2 Content-Type: application/json {"prefs":{"automaticSnapshots":false}}
(5)(+0000037): POST /connector/ping HTTP/1.1 Host: 127.0.0.1:23119 Connection: keep-alive Content-Length: 2 X-Zotero-Version: 5.0.60 Origin: chrome-extension://ekhagklcjbdpajgpjgmbionohlpdbjgc X-Zotero-Connector-API-Version: 2 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 DNT: 1 Content-Type: application/json Accept: */* Sec-Fetch-Site: cross-site Sec-Fetch-Mode: cors Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9
(5)(+0000003): HTTP/1.0 200 OK X-Zotero-Version: 5.0.78 X-Zotero-Connector-API-Version: 2 Content-Type: application/json {"prefs":{"automaticSnapshots":false}}
I've posted report id and debug id here
@retorquere I've noticed the following. In my linux box I have the 5.1.166 Version of BBT which cause the issues that everyone reported. On my macbook I've had zotero open for days so that lead to BBT not being updated automatically when restarting zotero. The version that I have there is 5.1.164 Version BBT which works fine.
So the problem is somewhere between these two versions I guess.
A suggestion would be to roll back to version 5.1.164 so that everyone has a working version till you figure out what's going on?
Edit: It seems that Version 5.1.167 of BBT solved my issues :) :+1:
Same here, that fixed it.
Super. Waiting for confirmation from @JonasDralle before I close the issue.
Hi! Thansk for responding so quickly! Is the update vailable via usual update mechanism or shoud I install the github release manually?
I've noticed that the columns of the main Zotero table got messed up during the update.
@JonasDralle either will work, I recommend via usual update mechanism. You can force a check for updates in the gear menu in the addons screen.
The columns will become normal again when BBT is installed and you've restarted. There's nothing I can do about the columns going haywire, if there are non-Zotero columns in the middle pane Zotero remembers their position, but if the corresponding plugin is uninstalled without first cleaning that out, Zotero does what you see now. I can't do anything about that.
@dstillman wrt the column mess: I currently note in an uninstall listener that BBT is about to be uninstalled, and then rely on zoteroPane being reloaded while BBT is still running so that I can remove the BBT column from pane.persist
Upside of the current state of affairs is that the column state actually gets persisted, if Zotero would scrub unknowns from pane.persist
at start it would likely get at that data before I could, so it would be lost at every start. Downside is of course that if the uninstall handler doesn't run for some reason (such as an early init failure like this issue), it also can't scrub the data.
Running the updater fixed this issue for me. @dstillman's suggestion here worked to reset the columns.
@augustjanse thanks, that's a relief to hear. I'd still prefer to hear from @JonasDralle -- this bug shook me some, despite the fact that I think I understand fully why it happened and why the fix works, 100% confirmation for reports would be nice.
@dstillman it's a little hard for me to test because I've forgotten how to build Zotero from source, but I believe the columns going all-selected is because in the case that a column has been serialized into pane.persist
, but that column does not exist in the XUL, there will be a gap in the ordinal
s and that causes firefox so show all columns for some reason; I can replicate this by just changing one of the ordinal
s to something just one larger than the current range, causing a gap.
I think the code below should counteract this, but a) I'd want to build from source to test this, and b) it'd be good to know if Zotero is interested in a PR for this.
/**
* Unserializes zotero-persist elements from preferences
*/
this.unserializePersist = function () {
_unserialized = true;
var serializedValues = Zotero.Prefs.get("pane.persist");
if(!serializedValues) return;
serializedValues = JSON.parse(serializedValues);
let ordinal = 0
serializedValues = Object.entries(serializedValues)
.map(([id, value]) => ({ id, value, el: document.getElementById(id) })) // get ids, values and elements
.filter(ser => ser.el) // remove entries without corresponding elements
.sort((a, b) => parseInt(a.value.ordinal || 0) - parseInt(b.value.ordinal || 0)) // sort by order
.map(ser => { // force no gaps in ordinals
if (typeof ser.value.ordinal === 'string') ser.value.ordinal = `${(ordinal = ordinal + 1)}`
return ser
})
for(var ser in serializedValues) {
for(var attr in ser.value) {
// Ignore persisted collapsed state for collection and item pane splitters, since
// people close them by accident and don't know how to get them back
// TODO: Add a hidden pref to allow them to stay closed if people really want that?
if ((ser.el.id == 'zotero-collections-splitter' || ser.el.id == 'zotero-items-splitter')
&& attr == 'state'
&& Zotero.Prefs.get('reopenPanesOnRestart')) {
continue;
}
ser.el.setAttribute(attr, ser.value[attr]);
}
}
if(this.itemsView) {
// may not yet be initialized
try {
this.itemsView.sort();
} catch(e) {};
}
};
Everything works now. Thanks for the quick fix!
Report ID: ? (Doesn't work)
Expected behavior:
Zotero should not crash.
Actual behavior:
After Zotero updated itself to version 5.0.78, clicking any item in the library replaces the library view with the text
An error has occurred. Please restart Zotero. You can report this error by selecting "Report Errors..." from the Help menu.
.Disabling the better bibtex addon "solves" the problem. I tried reporting the issue using "Send Better BibTeX debug report" as stated above, but absolutely nothing happens when I select it. I presume I should have gotten an ID back.
I have however included below the error log from the "report errors" window (which is presumably what the Zotero developers use): zotero_errors.txt
For now I will be attempting to downgrade Zotero and hope that fixes it.