RFR: 8341438: TextFlow: incorrect caretShape(), hitTest(), rangeShape() with non-empty padding/border [v2]

[Michael Strauß]

On Fri, 27 Jun 2025 15:02:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## Summary
>> This change adds new methods to the `TextFlow` which work correctly in the presence of non-empty insets (borders/padding). For backward compatibility, the old buggy methods are getting deprecated (not for removal). Also, adds new methods in Text which provide missing functionality.
>> 
>> ## Problem
>> A number of methods in `TextFlow` fail to return correct values in the presence of non-empty insets (i.e. when either padding or border are set):
>> - caretShape 
>> - hitTest 
>> - rangeShape
>> 
>> Additionally, the current API fail to provide strike-through shape, and account for line spacing in the range shape, a problem shared between the `TextFlow` and the `Text` classes.
>> 
>> ## Solution
>> The solution is two-fold: 
>> 1) deprecate the buggy methods (not for removal), adding explanations in their javadoc comments 
>> 2) add new methods that behave correctly in the presence of non-empty insets and/or implementing the missing functionality.
>> 
>> The proposed solution retains the buggy methods for the purposes of backward compatibility in applications which employ the workarounds, while providing new APIs with additional parameters similar to those offered by the new TextLayout API https://bugs.openjdk.org/browse/JDK-8341670
>> 
>> ## Testing
>> 
>> Additional visualization of the data returned by the new APIs is available in the Monkey Tester using the following branch (in the Text and TextFlow pages):
>> 
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.insets.corrected
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:
> 
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge branch 'master' into 8341438.text.shapes.insets
>  - layout info
>  - tests
>  - Merge remote-tracking branch 'origin/ag.text.layout.api' into 8341438.text.shapes.insets
>  - cleanup
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - cleanup
>  - ... and 60 more: https://git.openjdk.org/jfx/compare/b9dd4dec...236c6af1

I'm a bit skeptical with this approach. You describe the existing methods as "buggy". If that's the case, being good stewards of the API should point us towards fixing the bugs instead of adding new methods that seem confusingly similar.

The JBS ticket includes the following information:

> This bug might present a compatibility risk for existing applications which tried to compensate for it by getting the borders and padding from the corresponding Nodes and adding it to each path element (or setting translateX/Y).

Is this just a guess, or do you have any data to corroborate the problem? Messing up the API and baking "buggy" implementations into JavaFX forever should require quite a bit of justification.

Have alternatives been discussed? For example, we could have a system property to fall back to the old behavior.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1817#issuecomment-3046484454