Cursor jumps away from the search field

[radeksimik]

JabRef version 3.6 on Mac OS X 10.11.6

Steps to reproduce:

1. Typing a string to be searched into the search field on the top left of the window.
2. At the same time, the entry editor (at the bottom) is open.
3. Problem: Sometimes (didn't find the pattern) the text-cursor jumps away from the search field into one of the slots of the entry editor. From that point on, typing happens not in the search field but in the slot of the entry editor. This can cause retyping (so: deletion and then typing) of some of the information within the entry editor. (Luckily, this can undone by the Undo command.)

Essentially, this problem makes me search only when the entry editor is closed/deactivated. Pretty annoying.

Put the excerpt of the log file here

[AEgit]

I can confirm this problem - unfortunately I've also not been able to find the pattern behind it, so I did not report the bug.

[cr333]

Same for me with JabRef 3.6 on Windows 10 (1511). The cursor jumps away sometimes (but not every time) when the partial search term is a valid text completion. For example, searching for "bilateral" may mean that the cursor jumps away after "bi" as this is the surname of some author (Bi). But this is somehow not reproducible.

[lenhard]

I have been trying to reproduce this, but fail to do so. My cursor stays in the search field, also with search terms that are valid text completions.

Sorry, but as long as we haven't found a way of reproducing this, there is also no chance of fixing it.

[radeksimik]

It's frustrating. I just sat down to try to find the pattern, but have failed to reproduce the effect even once. I want to mention two points, just in case they help others look for the pattern:

• The target of the jumping was often (though not exclusively) the field "Crossref". The field is always empty in my database, so it's not the case that the target of the jumping is the string being searched for.
• My impression is that slow typing won't cause the jumping effect. It only seems to happen when I'm typing with all 10 fingers, in a significant speed.
• Don't know whether this matters, but my database is fairly large, containing 6000 entries.

I'll try to observe this further and let you know once I know more. The bug is pretty annoying mainly because it has a potential to mess up my carefully built database. I already started having bibtex-compilation problems because I've unintentionally added strings that caused trouble (e.g. into the "Crossref" field).

[AEgit]

I've also tried to reproduce it, but as you say it kind of happens in a random way. One point that you mention is interesting: You have a large database and so have I (currently >8000 entries). It would be interesting to see, if everyone who is affected, has a large database.

I also tried to reproduce the problem with a smaller database, but there it never happened (but I have to say, I only tried this for a couple of minutes, so maybe that's the reason).

[koppor]

Please try our latest build at https://builds.jabref.org/master. We worked on the search bar and it should be much better now.

[koppor]

@bartsch-dev Could you have a look at it? Use a large database with 10.000 entries.

[radeksimik]

The bug is back and I have some new observations:

Initial conditions (the first one is necessary, the second one maybe not):

1. The entry editor is open.
2. The cursor is within one of the fields of the entry editor.

Search & jump:

1. I intend to type "lenertova" in the search field.
2. I type "l" and the cursor immediately jumps into the entry editor, so I type "en" there before I manage to stop.
3. The place where it jumped was the top field of the entry editor - the Author field (in case the "General" tab was active, it jumped into the top field of that tab, i.e. Crossref).
4. It didn't delete the author, instead, the "en" was written immediately after the string already contained in that Author field (this corresponds to just starting to write into the Crossref field in case the "General" tab is active).
5. The entry it jumped into was the first one in the database that found some "l". That means that it was the very first one because virtually any entry contains an "l".

This is reproducible. I just tried searching for "kratzer", while having the "General" tab open. After writing "kra", the jump happened (to the first entry containing the string "kra" within the "General" tab), making me write "tz..." into the Crossref field of that entry.

Hope this helps!

[AEgit]

@radeksimik: Did you try the new master build? I ran into an additional (unrelated) problem with it. See here: #1993

[wilthan]

I see exactly the same issue as described by radeksimik. My database has >7000 entries.

[tobiasdiez]

Video of bug: #2137 (comment)

[ilippert]

I have a database with 9917 entries; I encounter the phenomenon, too.
I am quite certain, it does not happen if the editor shows the complete source.
Jabref 3.7, latest development from yesterday, on Fedora

[koppor]

I encounter the same issue with latest master (e9ed743). I have the entry editor open and just type something in the search field.

[matthiasgeiger]

We made some changes in the search behavior: If an entry editor is open, the search hits no longer get automatically selected, but the currently open entry is kept. (See #2129)

Wheres this is not directly related to this issue, it might also solve it as it may fix the incorrect/undeterministic behavior of jumping to the first text field in the entry editor if a search hit is selected.

Could you please test on of the current development builds whether the problem is solved there?

You can find the builds here: http://builds.jabref.org/master/

(Side note: in comparison to 3.6 the position and the semantic of the search field has changed: the search is now a global search where the search can be executed for each open bib database upon switching tabs (by clicking on the "globe" symbol))

[ilippert]

This seems to work quite well; at least after testing for 5 minutes I do not seem to encounter the issue anymore...

[radeksimik]

Thanks, @matthiasgeiger, this seems to have solved the issue for me as well!

[lenhard]

Good to hear! So we can close this.

[AEgit]

Yes, I was reluctant to report anything, because (as mentioned above) this error did not appear in a deterministic way, but so far it seems as if the problem was solved with the latest development version.