JDK-8248914 : Javafx TextField positions the cursor incorrectly after pressing DEL key
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: jfx11,8,jfx14,jfx15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2020-07-04
  • Updated: 2023-12-08
  • Resolved: 2023-12-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
jfx22 b21Fixed
Related Reports
Relates :  
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
I have a Windows 10 machine.
I could reproduce it in Java 8, Java 11, Java 14, and Java 15

A DESCRIPTION OF THE PROBLEM :
If use your mouse to click on the TextField to position the cursor right before a character, then if you press DEL key to delete the said character, you will notice that the cursor will be shifted one character to the left instead staying put.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the following sample code.
2. Use your mouse to click on the exact spot between 'a' and 'b' characters (edit 2023/11/30: more correctly, trailing edge of 'a', the leading edge of 'b' seems to work). This will put the cursor right after 'a'.
3. Press the DELETE key in your keyboard.

Note: You have to use your mouse to click on 'b'  to move the cursor there. If you use your keyboard arrow keys to move the cursor there then this bug won't happen.

Also make sure to press DELETE key, not the BACKSPACE key.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Character `b` should be deleted and the cursor should not move (remain at AFTER `a` character).
ACTUAL -
Character `b` is deleted but the cursor moves to left. It will end up at BEFOR the `a` character.

---------- BEGIN SOURCE ----------
TextField text1 = new TextField("abc");
TextField text2 = new TextField("abc");
HBox root = new HBox(text1, text2);
Scene scene = new Scene(root, 800, 600);
stage.setScene(scene);
stage.show();
---------- END SOURCE ----------

FREQUENCY : always


edit 2023/08/22: also reproducible on macOS 13.3.1a
edit 2023/11/30: steps to reproduce: it's important to click on the trailing edge of 'a' char.  clicking on the leading edge of 'b' char appear to work fine.
Comments
Changeset: 2108ecf9 Author: Karthik P K <kpk@openjdk.org> Date: 2023-12-06 03:51:34 +0000 URL: https://git.openjdk.org/jfx/commit/2108ecf9d7c8c459964a9e8b5e37485b3507b028
06-12-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jfx/pull/1287 Date: 2023-11-14 10:24:20 +0000
01-12-2023

I agree, the listeners are fishy and some code runs multiple times because of this. But the bias still looks weird. I found out that it matters where you click. Lets say we have an 'A'. If you click between first 50% of the letter, the forward bias is set to false, if you click between the remaining 50%, it will be set to true. I don't get, why. But also true, that there is some RTL handling as well for this.
05-05-2022

it's not so much the bias as such but its toggling back/forth somewhere "in between" stable text states - I suspect some fishyness in mixing changeListeners into the (mostly) invalidation listener chains that lead to calculating the offset at some intermediate state updating the visuals which is never reset (it seems to be visuals only, the offset as such is correct at the end).
05-05-2022

I had a look on this and the problem here is the 'forward bias'. I understand how it is calculated - but I see no use in it. Beside, it is responsible for this bug. I also once set the forward bias always to true and did heavy testing but everything still works. Does somehow know what this is actually used for? I didn't saw any usecase. I may will ask this soon on the mailing list as well.
02-05-2022

This is not a regression and not a new issue. It reproduces in JDK 8 GA as well.
07-07-2020

also see comments to https://stackoverflow.com/q/62721313/203657 for some preliminary digging - couldn't nail it, but looks like something fishy going on. Would suggest to uppen priority to p3: there is no work-around and user experience is severely hampered. Particularly, since after being in that trap at the end the text - with the caret visible before the last char - and pressing right there is no reaction (because the text caret is already after the last char)
07-07-2020

Test Result: ============= 8u251: Fail 11.0.7:Fail | javafx-sdk-11.0.2 14.0.1:fail | javafx-sdk-14.0.1 15ea29:fail | javafx-sdk-15ea+7 Moving the bug to JDK for the development team's assessment.
07-07-2020