space character causes cursor to jump to start of line #3471
Comments
|
I noticed that this happens sometimes on my windows system, too. But I just can not really reproduce it, But at least you got an exception in your log (maybe an other issue but still helpful) |
|
I also had it today. Not sure about the origin (no exception on my side). |
tobiasdiez
added
bug
|
I can confirm this on Linux x86_64 with the above setup (but no exception). |
|
Temporary workaround: if you type any character into a field, say "x", you can then enter data normally to the left of the "x". It's acting as a sort of terminator, and stops the cursor misbehaving when space is entered. |
|
I'll have a look at this issue this weekend, if nobody else is quicker. |
|
It's a bit strange but I can no longer reproduce this bug. Can you please check the recent development version and see if it is also fixed for you. Thanks. |
tobiasdiez
added
the
status: waiting-for-feedback
|
I tried the latest devel version and can reproduce. |
|
Just tested with the 12-19 build (finally) and the issue seems to be resolved. |
|
I'm sorry, but I'm still getting the jumping behaviour.
JabRef 4.1-dev--snapshot--2017-12-19--master--07652a93f
Linux 4.10.0-42-generic amd64
Java 1.8.0_151
<details>
<summary>Detail information:</summary>
```
Opening: /home/dom/Dropbox/Projects/HSSA/issue 5.2 rasayana
issue/Cantwell/paper/Cantwell.bib
Opening: /home/dom/Dropbox/Projects/HSSA/issue 5.1e Birch/paper/Birch.bib
Opening: /home/dom/Dropbox/localtexmf/bibtex/bib/biblio4-utf8.bib
```
</details>
--
Professor Dominik Wujastyk <http://ualberta.academia.edu/DominikWujastyk>
,
Singhmar Chair in Classical Indian Society and Polity
,
Department of History and Classics <http://historyandclassics.ualberta.ca/>
,
University of Alberta, Canada
.
South Asia at the U of A:
sas.ualberta.ca
…On 19 December 2017 at 09:17, Christoph ***@***.***> wrote:
Closed #3471 <#3471>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3471 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAuhhrjCMATROWgRy6AeEH7gV1PTJU4cks5tB-GZgaJpZM4QvLpf>
.
|
|
Oh yes, I am sorry I tested in the source editor but in the other window it does jump. |
|
I can confirm this behavior in version 4.1. |
|
Seems to be cured! Hurrah! JabRef 4.2-dev--snapshot--2017-12-29--master--7a578deba |
|
Not fixed...go to the "Optional fields" and try to type a multi word note e.g. "this is a note". I think you only checked the entry source editor. |
|
No, I was typing into the fields of the main entry editor - not the source
editor - and the jumping didn't happen.
But I've just tried again on a different Linux installation, and the
jumping *does* still happen.
I think this means there is some interaction between the field-editing and
something in the Linux installation or environment.
Later this evening, I'll re-check the behaviour on the first machine again
and see whether it still doesn't demonstrate the bug.
But, sadly, #3471 does indeed need to stay open.
Best,
Dominik
…On 30 December 2017 at 12:14, sambo57u ***@***.***> wrote:
Not fixed...go to the "Optional fields" and try to type a multi word note
e.g. "this is a note". I think you only checked the entry source editor.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3471 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAuhhthoVRQAQmBwgMKg9sxTSMLeRnvAks5tFouxgaJpZM4QvLpf>
.
|
lenhard
removed
the
status: waiting-for-feedback
|
I found an interesting twist to this issue. My @manuscript entries look like this: @manuscript{cam-add1049, JabRef 4.2-dev--snapshot--2018-01-06--master--560678f47 |
|
JabRef 4.2-dev--snapshot--2018-01-10--master--5cbeb2baa Seems to be solved on my laptop which exibited the problem in the past. Thank you!!! |
|
It is still there for me. It does not happen in the source editor but in the other panes, like Optional fields. |
|
Still seeing this problem in panes such as 'Required Fields' and so on JabRef 4.2-dev--snapshot--2018-01-10--master--5cbeb2baa Restarting JabRef seems to cure the problem for a while, sometimes. |
|
I still see this problem in all text fields. I have tried all development versions up to JabRef_windows-x64_4_2-dev--snapshot--2018-01-16--master--57f954da8.exe I see the issue also with 4.1 stable version |
|
JabRef 4.2-dev--snapshot--2018-01-16--master--57f954da8 I can confirm that since "JabRef 4.2-dev--snapshot--2018-01-10--master--5cbeb2baa" my cursor is behaving as it should in all text fields, both normal editing fields and the biblatex source field. This cure is present on three laptops and a desktop that I use routinely, all running Linux Mint in the same configuration as above. This is a naughty one, isn't it. I must be sensitive to some particular combination of settings or environments. |
|
It is still there with your version here! It is just the space bar that makes the cursor go to the beginning of the line. If one just types in normal characters it is ok, I wonder why this is so hard to fix. |
|
JabRef 4.2-dev--snapshot--2018-01-16--master--57f954da8 Dang it! The bug reasserted itself. Same version of everything that I was using 20 hours ago when all was fine! Since then, I've had the laptop in suspend state, and done a standard system update (mainly DNS and bind9 stuff, but a mesa-vdpau-drivers update too). [edit, about four hours later] |
|
Still seeing the problem. JabRef 4.2-dev--snapshot--2018-01-18--master--731a743c6 The bug appears to be related to switching to the Bibtex source tab and then away to specific other editor tabs.
It appears that the bug does not affect the review, abstract or bibtex source tabs. I don't have access to my mac or linux machine ATM so cannot confirm the behaviour on those platforms. |
|
Excellent observations, Simon @sjbutler! I have tried your steps and reproduced exactly the behaviour you describe. The immune fields you mention, review and abstract, are the "General Fields" in JabRef parlance, as I'm sure you know. They're set up from the Options menu, not the Bibtex menu. JabRef 4.2-dev--snapshot--2018-01-16--master--57f954da8 |
|
Thank you Dominik (@wujastyk) for taking the time to check on Linux. Confirmed that the same steps reproduce the problem on a mac in JabRef 4.2-dev--snapshot--2018-01-18--master--db3a3b257 So a workaround appears to be to edit entries using either the Bibtex Source editor or the other tabs, but not both in the same session. |
|
@sjbutler I wouldn't use the source editor tab either. I experienced that, once an entry was opened in the source editor (whether it was actually edited or not doesn't seem to play a role), it frequently was replaced by some other entry in the bib file. The next time I opened it, I had a duplicate and the original entry was gone. |
|
This was an old bug I reported that has been fixed in the dev version. Is this really happening again with the dev built? |
|
I experienced it recently on one of my machines. I am waiting for the next stable release to upgrade and test it again. |
|
Can confirm this behavior. Reproducible as @sjbutler says. |
|
Just debugged a bit. It is a problem of either the bidirectional binding itself or inside the view model! @tobiasdiez As a side note - Looks like autocompletion on each field is always called even if it is globally disabled inside the settings. |
|
Multi Line fields and enter are even worse. it locks the cursor on the line start #3622 |
|
In case it's relevant, ever since IBUS input system support was added to
JabRef, it has not been possible to use it to type foreign characters in
the "biblatex source" tab, but only in the "Required fields" and other tabs.
…On 24 January 2018 at 08:59, Stefan Kolb ***@***.***> wrote:
Multi Line fields and enter are even worse. it locks the cursor on the
line start #3622 <#3622>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3471 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAuhhl1Ug2AvHPv0jQlpd5-WqE8n22Skks5tN1NngaJpZM4QvLpf>
.
|
|
Regarding the foreign characters input, this is an official Java bug which we had to backport. |
|
I think (or better hope), that this issue should be fixed as part of #3591. Update: it is not, at least not at the moment. |
|
This is fixed by #3699 The fix is merged into master. |
|
What a huge relief. Thank you! |
|
Thank you. Can confirm the problem is fixed in 2018-02-06 snapshot build running on windows 7. |
JabRef 4.1-dev--snapshot--2017-11-27--master--42a959d1d
Linux 4.10.0-40-generic amd64
Java 1.8.0_151
I don't understand why nobody else has reported this, since it makes JR unusable. It's been an issue for over a week. I guess it's a local problem on my system. I normally run IBUS and the m17n keyboard library, but this problem still exists if I unload those utilities.
Maybe there's something else going on with my space-key?
Log copy:
Opening: /home/dom/Dropbox/localtexmf/bibtex/bib/biblio4-utf8.bib
Uncaught exception occurred in Thread[JavaFX Application Thread,5,main]
java.lang.NullPointerException
at org.jabref.gui.search.GlobalSearchBar.lambda$new$5(GlobalSearchBar.java:196)
at com.sun.javafx.application.PlatformImpl.lambda$null$172(PlatformImpl.java:295)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$173(PlatformImpl.java:294)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at com.sun.glass.ui.gtk.GtkApplication.lambda$null$48(GtkApplication.java:139)
at java.lang.Thread.run(Thread.java:748)
The text was updated successfully, but these errors were encountered: