RFR: 8364049: ToolBar shows overflow menu with fractional scale [v2]
Michael Strauß
mstrauss at openjdk.org
Wed Jul 30 16:37:08 UTC 2025
On Tue, 29 Jul 2025 18:46:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:
>> This is a very localized fix for the issue described in https://bugs.openjdk.org/browse/JDK-8364049 which resulted from comparing snapped and non-snapped values. The issue seems to happen only with fractional scale, that is, on Windows at 125%, 150%, 175% etc. scales.
>>
>> ---
>>
>> While looking at the `ToolBarSkin` code, I noticed a general pattern related to snapping, that might cause similar issues in the tool bar skin and elsewhere. Here is an example in `ToolBarSkin::computePrefWidth()` in L411:
>>
>>
>> if (toolbar.getOrientation() == Orientation.HORIZONTAL) {
>> for (Node node : toolbar.getItems()) {
>> if (!node.isManaged()) continue;
>> prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();
>> }
>> prefWidth -= getSpacing();
>> } else {
>>
>>
>> the general issue, in my opinion, is that doing `prefWidth += snapSizeX(node.prefWidth(-1)) + getSpacing();` results in the `prefWidth` value differ from its snapped value. In other words, whenever computation involves snapped values, the result must be snapped as well - and that includes the case when all the parts of the computation are snapped.
>>
>> Another, related, topic is how to properly snap the values in the computation. I would say ideally it should be done like this:
>>
>>
>> snappedResult = snap(snap(value1) .OP. snap(value2) .OP. ... snap (valueN))
>>
>>
>> It might be possible to skip the snapping of intermediary values, and only snap the result, but one must be careful not to accumulate errors.
>>
>> Getting back to the ToolBarSkin, one can see the issue on LL392, 399, 411, 417, 425, 436, 530, and so on.
>>
>> I decided not to fix the snapping for the purpose of making this PR narrow in scope with the goal to backport it to jfx25, but I did want to describe the issue.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>
> - Merge branch 'master' into 8364049.toolbar
> - snap length
modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 692:
> 690: */
> 691: private int getOverflowNodeIndex(double length) {
> 692: if (getSkinnable().getOrientation() == Orientation.VERTICAL) {
Snapping the input argument of a method like `getOverflowNodeIndex` doesn't seem right to me, because the length is computed incorrectly in the first place. Have you considered fixing the snapping in `getToolbarLength`? This also solves the problem.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1856#discussion_r2243271568
More information about the openjfx-dev
mailing list