On Mon, 15 Nov 2021 14:34:04 GMT, Marius Hanl <mh...@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
