The fix uses character BreakIterator instead of the logic that relies on caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
I believe this is a more reliable method of navigation, as it behaves in sync with the jdk break iterator, thought it might work differently around grapheme clusters, considering a recent change JDK-8291660 This change also introduces TextInputControlHelper class (impl. detail) which gives access to character- and word- break iterators cached by TextInputControl (*some say* these iterators and associated editing logic should be a part of Content implementation, but that's a discussion for another day). ------------- Commit messages: - added robot test - exposing cached break iterators - using break iterator Changes: https://git.openjdk.org/jfx/pull/1220/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1220&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296266 Stats: 347 lines in 4 files changed: 255 ins; 60 del; 32 mod Patch: https://git.openjdk.org/jfx/pull/1220.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1220/head:pull/1220 PR: https://git.openjdk.org/jfx/pull/1220
