RFR: 8277122: SplitPane divider drag can hang the layout

[Jeanette Winzenburg]

On Mon, 15 Nov 2021 14:34:04 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**.
> While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider.
> 
> This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions)
> 
> -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout.
> 
> This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it).
> 
> Note: I also fixed a simple typo of a private method in SplitPaneSkin:
> initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers

interesting issue - and fix :) Verified the mis-behaviour before the fix and its working after.

Wondering, though (read: I don't understand ��) 

- why the layout details in the splitpane hinders the visual update of a completely unrelated component (like the combo)?
- why does it only happen on increasing the divider pos, not on decreasing?

As to the test: would prefer to also see a test of the fixed effect (vs. the fix implementation of not re-entering layout) - might be a bit tricky, though.

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

PR: https://git.openjdk.java.net/jfx/pull/669