RFR: 8364049: ToolBar shows overflow menu with fractional scale [v2]

Andy Goryachev angorya at openjdk.org
Tue Jul 29 18:46:44 UTC 2025


> 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

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1856/files
  - new: https://git.openjdk.org/jfx/pull/1856/files/c69f29ff..aa802f4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1856&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1856&range=00-01

  Stats: 1623 lines in 14 files changed: 1614 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1856.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1856/head:pull/1856

PR: https://git.openjdk.org/jfx/pull/1856


More information about the openjfx-dev mailing list