RFR: 8371067: RichTextArea: requestLayout by inline node doesn't reach VFlow [v2]

[Marius Hanl]

On Fri, 21 Nov 2025 15:39:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Let me repeat what I mean:
>> - If you call: `setManaged(false)`, you will effectively tell JavaFX: I'm the layout root, I can handle ALL layout changes from my children without my parents.
>> - This is not the case here, so making the `TextCell` unmanaged while still retrieving a parent (`VFlow`) fights this design.
>> - Which leads me to the conclusion: Maybe this should not be unmanaged, since it does not fulfill the required preconditions
>> - Checking the `VirtualFlow` as an example, it will not set anything to unmanaged
>> 
>> Lets check some existing examples of unmanaged nodes:
>> 
>> `XYChart`. See how this was done by design, the consequences were known:
>> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/chart/XYChart.java#L523-L525
>> 
>> ---
>> 
>> `ScrollPaneSkin` has actually the same case as you. This is how they dealt with it:
>> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L652-L653
>> https://github.com/openjdk/jfx/blob/33abf5d4b3d2b90f66581c4e25c542adf285fadd/modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java#L679-L689
>> 
>> This could be a solution for your problem. Since they also set the parent `viewRect` as unmanaged, the layout request will never hit the `ScrollPane`. But with that solution the child of the `viewRect`, called `viewContent` does request the `ScrollPane` layout. A clever solution without anything like ancestor searching. What do you think?
>
> The documentation on `Node.managed` property states 
> 
> Defines whether or not this node's layout will be managed by its parent. 
> 
> 
> The layout of TextCell is not managed by its parent (`VFlow.content`), **by design**.
> 
> The `VFlow` is the entity that does the layout, for a reason.  It's a complicated thing, and multiple moving parts are connected (one example: it performs multiple layout cycles in the same layout pass when scrollbars appear/disappear during the layout pass, to avoid jumping and flicker - something we occasionally see with `ScrollPane` and `ListView`, see Note 1).
> 
> Notes
> 
> 1. I occasionally see the continuous flicker/layout when resizing the list of pages in the latest Monkey Tester, but so far I was unable to capture the exact conditions to create a reproducible test case (this is unrelated to this PR)

Did you read what I wrote above? I made multiple suggestions as how we can deal with the situation, even without making things managed again.

To reiterate, what is the problem?
- We now have a dependency from `TextCell` to `VFlow`. Not explicitly, but rather hidden, by searching all parents (which is also costly when doing that often). I would prefer a clear separation of concerns
- This makes subclassing/extending harder. What happens, if I want to write my own `VFlow`, but still use everything else, including `TextCell`? What if I want to use `TextCell` for a component, that has no `VFlow`? What happens if we find a `VFlow` from another component even? Because we used the `TextCell` somewhere else?
- Other components made it clear how to use `managed` and `unamanged` nodes. And how to bubble up a request still. Why do we want to make an exception here? This is the first time we need to search the parent hierarchy
- Why not e.g. binding to the `needsLayoutProperty` from a `TextCell` from within `VFlow` and just request the layout when set?

Also another point: The test is green for me with the changes from: https://github.com/openjdk/jfx/pull/1945
So I would like to know, if maybe there was a bug even?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1975#discussion_r2553234576