On Wed, 30 Sep 2026 13:58:03 GMT, Robert Lichtenberger <[email protected]> wrote:
> As analysed in the bug, the previousWord() method does not work correctly if > at the word boundary a character is found that is neither letter nor digit. > This fix changes the method so that only ranges of whitespace will be > skipped, resulting in correct word selection behaviour. > A test case has been added to TextAreaTest. > gradlew :controls:test --tests test.javafx.scene.control.Text*Test has been > executed to ensure no regressions happen in other text related classes. No > errors were reported. > > > --------- > - [X] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). This is a step in the right direction. This function has been broken forever, as well as many others in TextInputControls. The proposed solution may not be sufficient - there are still some scenarios that don't seem to work as expected. What is expected is a subject to debate, of course. So perhaps we should start with defining the expected behavior (perhaps in the form of tests, see [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) ☂ Develop Behavior Test Suite). We should also be aware that sometimes the behavior differs between the platforms, which is also, in my opinion, subject to debate. For example, I don't expect platform-specific behavior when double clicking to select a word, but the behavior of TextArea on Windows is different that on the other platforms for reasons that are unknown to me. Getting back to the PR, here are a few scenarios, comparing this PR to MS Word and TextEdit on macOS. I am going to use the symbol | to indicate the double click position, and symbols [ and ] to indicate the result of the selection: bug #1|23 -> bug [#123] ms word, TextEdit: bug #[123] aaa.3|x3 -> aaa[.3x3] -"- aaa.[3x3] aaa |bbb -> [aaa] bbb -"- aaa [bbb] aaa,|,,bbb -> aaa,[,],bbb ms word: aaa[,,,]bbb TextEdit: aaa,[,],bbb aaa | bbb -> [aaa] bbb ms word: [aaa ]bbb TextEdit: aaa[ ]bbb One thing I have to say is that Word works more intuitively than anything else. Having said that, the application might have different requirements, so it should be possible to change the behavior, but that's a different topic (one possible solution is to use an InputMap, see [JDK-8314968](https://bugs.openjdk.org/browse/JDK-8314968) ). Another possible issue is that the implementation uses `BreakIterator` set to the default locale, which may or may not be what application requires. For instance, a translation app might need an editor explicitly set to another locale, and currently there is no way to do that, as far as I can tell. I am not sure how to proceed. We can continue with this PR as a quick fix of what is an obvious, to be followed up by a wider discussion and the actual fix. Or perhaps we should spend some time defining the expected behavior before attempting the fix. What do you think? modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 1760: > 1758: return Character.isWhitespace(c); > 1759: } > 1760: minor: extra newline modules/javafx.controls/src/test/java/test/javafx/scene/control/TextAreaTest.java line 565: > 563: > 564: // test against JDK-8264588 > 565: @Test public void previousWord() { minor: `@Test` should be on its own line ------------- Changes requested by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2334#pullrequestreview-5368376033 PR Review Comment: https://git.openjdk.org/jfx/pull/2334#discussion_r4146315603 PR Review Comment: https://git.openjdk.org/jfx/pull/2334#discussion_r4146321270
