Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

space character causes cursor to jump to start of line #3471

Closed
wujastyk opened this issue Nov 29, 2017 · 37 comments
Closed

space character causes cursor to jump to start of line #3471

wujastyk opened this issue Nov 29, 2017 · 37 comments
Labels
bug Confirmed bugs or reports that are very likely to be bugs entry-editor ui
Milestone

Comments

@wujastyk
Copy link

JabRef 4.1-dev--snapshot--2017-11-27--master--42a959d1d
Linux 4.10.0-40-generic amd64
Java 1.8.0_151

  1. Open JR
  2. Go to one of the editing tabs
  3. Go to the end of a piece of text, like author or title
  4. Press space bar
  5. Cursor repositions itself at the start of the line. This happens with all subsequent space-bar presses.

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)

@Siedlerchr
Copy link
Member

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)

@Siedlerchr Siedlerchr added the ui label Nov 29, 2017
@tobiasdiez
Copy link
Member

I also had it today. Not sure about the origin (no exception on my side).

@tobiasdiez tobiasdiez added bug Confirmed bugs or reports that are very likely to be bugs entry-editor labels Nov 29, 2017
@sambo57u
Copy link

I can confirm this on Linux x86_64 with the above setup (but no exception).

@tobiasdiez tobiasdiez added this to the v4.1 milestone Nov 30, 2017
@wujastyk
Copy link
Author

wujastyk commented Dec 4, 2017

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.

@tobiasdiez
Copy link
Member

I'll have a look at this issue this weekend, if nobody else is quicker.

@tobiasdiez tobiasdiez self-assigned this Dec 6, 2017
@tobiasdiez
Copy link
Member

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 tobiasdiez added the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Dec 8, 2017
@tobiasdiez tobiasdiez mentioned this issue Dec 8, 2017
6 tasks
@sambo57u
Copy link

sambo57u commented Dec 8, 2017

I tried the latest devel version and can reproduce.

@tobiasdiez tobiasdiez removed their assignment Dec 8, 2017
@sambo57u
Copy link

Just tested with the 12-19 build (finally) and the issue seems to be resolved.

@wujastyk
Copy link
Author

wujastyk commented Dec 19, 2017 via email

@sambo57u
Copy link

Oh yes, I am sorry I tested in the source editor but in the other window it does jump.
Please reopen!

@Siedlerchr Siedlerchr reopened this Dec 19, 2017
@koppor koppor modified the milestones: v4.1, v4.2 Dec 22, 2017
@j0hannes
Copy link

I can confirm this behavior in version 4.1.

@wujastyk
Copy link
Author

Seems to be cured! Hurrah!

JabRef 4.2-dev--snapshot--2017-12-29--master--7a578deba
Linux 4.10.0-42-generic amd64
Java 1.8.0_151

@sambo57u
Copy link

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.

@tobiasdiez tobiasdiez reopened this Dec 31, 2017
@wujastyk
Copy link
Author

wujastyk commented Dec 31, 2017 via email

@lenhard lenhard removed the status: waiting-for-feedback The submitter or other users need to provide more information about the issue label Jan 2, 2018
@wujastyk
Copy link
Author

wujastyk commented Jan 7, 2018

I found an interesting twist to this issue.
I have defined a private bibtex entry type, @manuscript. If I create a new @manuscript entry, this #3471 bug does not appear. Typing is normal.

My @manuscript entries look like this:

@manuscript{cam-add1049,
collection = {South Asian Collection},
location = {Cambridge},
library = {Cambridge University Library},
shelfmark = {Add.\ 1049},
catalog = {\cite[143]{bend-bmcat}},
}

JabRef 4.2-dev--snapshot--2018-01-06--master--560678f47
Linux 4.10.0-42-generic amd64
Java 1.8.0_151

@wujastyk
Copy link
Author

JabRef 4.2-dev--snapshot--2018-01-10--master--5cbeb2baa
Linux 4.10.0-42-generic amd64
Java 1.8.0_151

Seems to be solved on my laptop which exibited the problem in the past. Thank you!!!

@sambo57u
Copy link

It is still there for me. It does not happen in the source editor but in the other panes, like Optional fields.

@sjbutler
Copy link

sjbutler commented Jan 12, 2018

Still seeing this problem in panes such as 'Required Fields' and so on

JabRef 4.2-dev--snapshot--2018-01-10--master--5cbeb2baa
Windows 7 6.1 amd64
Java 1.8.0_151

Restarting JabRef seems to cure the problem for a while, sometimes.

@jmdesantos
Copy link

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
Windows 7 Professional
Java 1.8.0_151

I see the issue also with 4.1 stable version
The last version that I know didn't present this issue was
JabRef_windows-x64_4_1-dev--snapshot--2017-11-03--master--f5842eff2

@wujastyk
Copy link
Author

JabRef 4.2-dev--snapshot--2018-01-16--master--57f954da8
Linux 4.13.0-26-generic amd64
Java 1.8.0_151

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.

@sambo57u
Copy link

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.

@wujastyk
Copy link
Author

wujastyk commented Jan 18, 2018

JabRef 4.2-dev--snapshot--2018-01-16--master--57f954da8
Linux 4.13.0-26-generic amd64
Java 1.8.0_151

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]
I restarted JabRef after a writing session with LibreOffice, and it worked perfectly again. It's hard to know what is going on.

@sjbutler
Copy link

Still seeing the problem.

JabRef 4.2-dev--snapshot--2018-01-18--master--731a743c6
Windows 7 6.1 amd64
Java 1.8.0_151

The bug appears to be related to switching to the Bibtex source tab and then away to specific other editor tabs.

  1. Start JabRef and edit an entry using any editor tab other than the Bibtex Source tab, the bug is not present. Switch to the Bibtex source tab and then return to another editor tab (but not review or abstract tab) and enter a space, the bug appears.
  2. Start JabRef and select an entry for editing then switch to the Bibtex Source tab, then switch back to required fields or optional fields editor tab (but not review or abstract tab), add a space to a field and the bug is there.

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.

@wujastyk
Copy link
Author

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
Linux 4.13.0-26-generic amd64
Java 1.8.0_151

@sjbutler
Copy link

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
Mac OS X 10.13.2 x86_64
Java 1.8.0_151

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.

@j0hannes
Copy link

@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.

@sambo57u
Copy link

This was an old bug I reported that has been fixed in the dev version. Is this really happening again with the dev built?

@j0hannes
Copy link

I experienced it recently on one of my machines. I am waiting for the next stable release to upgrade and test it again.

@stefan-kolb
Copy link
Member

Can confirm this behavior. Reproducible as @sjbutler says.

@stefan-kolb
Copy link
Member

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.

@stefan-kolb
Copy link
Member

Multi Line fields and enter are even worse. it locks the cursor on the line start #3622

@wujastyk
Copy link
Author

wujastyk commented Jan 24, 2018 via email

@Siedlerchr
Copy link
Member

Regarding the foreign characters input, this is an official Java bug which we had to backport.

@tobiasdiez
Copy link
Member

tobiasdiez commented Jan 24, 2018

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.

@lenhard
Copy link
Member

lenhard commented Feb 6, 2018

This is fixed by #3699

The fix is merged into master.

@lenhard lenhard closed this as completed Feb 6, 2018
@wujastyk
Copy link
Author

wujastyk commented Feb 6, 2018

What a huge relief. Thank you!

@sjbutler
Copy link

sjbutler commented Feb 7, 2018

Thank you. Can confirm the problem is fixed in 2018-02-06 snapshot build running on windows 7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs or reports that are very likely to be bugs entry-editor ui
Projects
None yet
Development

No branches or pull requests

10 participants