I’ve been having some strange issues with the last two versions of jabref (3.5 and 3.6 versions) and unfortunately don’t have the time to dig into the problems and create extended bug reports. I’d like to go back to the last released v2 (2.8 or 2.9 or 2.10??) but can’t find a link anywhere - can someone please help?
EDIT: Nevermind, I found the previous versions on Sourceforge.
(FWIW, 2 of the main issues I have with v3 are:
jabref 3.6 keeps crashing (on Windows 7, java 8.101 32-bit)
entries get mixed up: i.e. I create a new bibtex entry, then go to the tab to add a link to the pdf file, but instead adds the pdf link to another bibtex entry… it’s as if jabref is highlighting a different entry even though I haven’t done anything besides change tabs – strange behavior).
Just a quick question: may it be that the entries have the same BIbTeX key? Unfortunately some operations rely on the key rather than the entry itself.
Crashes related to pressing save in the toolbar while having unbalanced brackets in a field have been sorted out in the development version after 3.6 was released. Other crashes we are very interested to be able to reproduce.
No, it seems to jump to some random other entry (with a different key). The workflow I use it:
1- Copy bibtex text (copy/paste from some website) into a new bibtex entry in the “bibtex source” tab
2- Go to the ‘Required fields’ tab and generate a new unique bibtext key (author+year) with the wizard button
3- Copy key to clipboard (Ctrl C)
4- Go back to web browser and save PDF with key as name
5 - Go to the ‘General’ tab and click “Auto” to automatically add PDF to “File” field
(note I have not clicked “save” at any point yet)
What happens is that AFTER I do step 5, it jumps to a different entry in the browser window and seems to add the file to another entry. I used the same workflow on v2.xx.
Anyway if I have some time later I will try to reproduce it. Not sure if the crashes were related to unbalanced brackets (i dont think so but not sure).
Is there any way to save some debugging info in case I have some time to look into this later?
The problem I described above seems very similar to this bug report you opened, except in my case the first entry that ends up with the unintended edits is an existing entry (rather than a newly created one, so they shouldn’t have the same (possibly empty) key), and I don’t ‘mark’ any of the entries, as far as I know: Issue # 1745 “Weird editing in empty entries”
It would be very helpful if you found out the version when this behavior was introduced. I know, the steps are very short, but we developers are currently very short of time and any external help supports us on focusing on other critical issues.
EDIT: For further debugging you could do a git bisect using the source code and gradlew clean run after each checkout.