Bug: ToolBar always using overflow menu whenever a scaled resolution set
Cormac Redmond
credmond at certak.com
Sun Dec 21 00:40:32 UTC 2025
Hi,
I want to re-raise this issue for discussion (Andy created a bug a while
back: http://bugs.openjdk.org/browse/JDK-8366739, simple reproducer code is
in the bug as well as previous mail in this thread).
See the "x" variable from code from ToolBarSkin. The trailing 0001 is due
to normal floating-point behavior, and is causing the x > length to be true
when we don't want it. This must be happening in the wild quite a bit.
[image: image.png]
Exactly what is causing the bug, is easily reproducible in Plain Java. So
is a fix, using a tolerance.
public class Float {
static void main() {
double separatorLength = 10.4;
double buttonLength = 99.2;
double x = separatorLength + buttonLength;
System.out.println("separatorLength: " + separatorLength);
System.out.println("buttonLength: " + buttonLength);
System.out.println("Sum: " + x);
// Output: Sum: 109.60000000000001
// Now for a potential fix.
// This is the "length" variable value in ToolBarSkin, as per
screenshot
double length = 109.6;
if(x > length) {
System.out.println("BUG: x is regarded as greater than length,
it should not be!");
}
// Create an epsilon, using scientific notation for 0.000000001
final double EPS = 1e-9;
// And change the comparison in ToolBarSkin from if(x > length) to:
if (x - length > EPS) {
// Won't happen now
} else {
System.out.println("FIX: with EPS tolerance, x is NOT greater
than length.");
}
}
}
Full output, proving it works:
separatorLength: 10.4
buttonLength: 99.2
Sum: 109.60000000000001
BUG: x is regarded as greater than length, it should not be!
FIX: with EPS tolerance, x is NOT greater than length.
Some questions:
- Is there any reason this would not be safe?
- Should we centralise this (or whatever the final fix is) somewhere? Or
are there already some utilities (I assume this sort of problem is
commonplace)?
Example of the bug appearing in the real-world:
[image: image.png]
Kind Regards,
Cormac
On Sat, 30 Aug 2025 at 01:20, Cormac Redmond <credmond at certak.com> wrote:
> Hi,
>
> A variation of this bug still persists (JFX 25-ea+28).
>
> Run this code (125% display scaling, on Windows):
>
> public class ToolbarBugApp extends Application {
>
> @Override
> public void start(Stage primaryStage) {
> ToolBar tb = new ToolBar();
> tb.getItems().addAll(
> new Separator(Orientation.VERTICAL),
> new Button("Create Schema")
> );
>
> BorderPane bp = new BorderPane();
> bp.setTop(new HBox(tb));
> primaryStage.setScene(new Scene(bp, 600, 400));
> primaryStage.show();
> }
>
> public static void main(String[] args) {
> launch(args);
> }
> }
>
> And you'll still see this:
>
> [image: image.png]
>
>
>
> Kind Regards,
> Cormac
>
> On Thu, 24 Jul 2025 at 16:12, Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> https://bugs.openjdk.org/browse/JDK-8364049
>>
>>
>> On 7/24/2025 7:15 AM, Kevin Rushforth wrote:
>>
>> This does look like a real bug. Thanks for filing it.
>>
>> Unfortunately one cannot attach screenshots on JBS submissions, so a text
>> description will have to do.
>>
>>
>> I have attached the two images to the bug. It will show up publicly, with
>> a JDK bug ID, soon.
>>
>> -- Kevin
>>
>>
>> On 7/23/2025 3:17 PM, Cormac Redmond wrote:
>>
>> I've a habit of finding non-bugs, so prefer to discuss it first to get
>> some feedback (and/or to avoid duplicating known bugs), but I assume this
>> is definitely an issue, so I created it on JBS now: 9078765...
>>
>> Unfortunately one cannot attach screenshots on JBS submissions, so a text
>> description will have to do.
>>
>> Thanks!
>>
>>
>> Kind Regards,
>> Cormac
>>
>> On Wed, 23 Jul 2025 at 20:30, Andy Goryachev <andy.goryachev at oracle.com>
>> wrote:
>>
>>> Do we have the JBS ticket filed for this issue?
>>>
>>>
>>>
>>> -andy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Cormac
>>> Redmond <credmond at certak.com>
>>> *Date: *Tuesday, July 22, 2025 at 12:08
>>> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>> *Subject: *Re: Bug: ToolBar always using overflow menu whenever a
>>> scaled resolution set
>>>
>>> Any thoughts on this? It seems like a definite JavaFX bug with hopefully
>>> a simple fix. Choosing any fractional scaled resolution may or may not
>>> cause the issue. I also wonder what other controls may suffer from the same
>>> issues.
>>>
>>>
>>>
>>> On Sat 19 Jul 2025, 19:01 Cormac Redmond, <credmond at certak.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I've traced the bug down to a rounding error. See the below screenshot
>>> in ToolBarSkin's getOverflowNodeIndex(double length).
>>>
>>>
>>>
>>> These two numbers are not equal, but should be. snapSizeX() ultimately
>>> ends up grabbing getSnapScaleX(), whose value would be 1.25. If it's 1
>>> (i.e., no scaling), we don't see this issue. If it's 1.25, we see this
>>> rounding difference between the two numbers in this instance. If these two
>>> numbers are not equal, the calling code mistakenly assumes the overflow box
>>> is necessary.
>>>
>>>
>>>
>>>
>>>
>>> Can someone fix this?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>> Cormac
>>>
>>>
>>>
>>> On Sat, 19 Jul 2025 at 18:33, Cormac Redmond <credmond at certak.com>
>>> wrote:
>>>
>>> Confusingly, make the string longer, such as "Create Schema 123 123 123":
>>>
>>>
>>>
>>> bp.setTop(new HBox(new ToolBar(new Button("Create Schema 123 123
>>> 123"))));
>>>
>>>
>>>
>>> ...and the overflow doesn't appear (but still, anything between and
>>> including 13-24, it does):
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>> Cormac
>>>
>>>
>>>
>>> On Sat, 19 Jul 2025 at 11:12, Cormac Redmond <credmond at certak.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> There's a bug whenever using a ToolBar on Windows if you set your
>>> resolution scale > 100% (which is quite common). E.g., 125%:
>>>
>>>
>>>
>>>
>>>
>>> E.g., this is what a ToolBar always renders if scale is 125%:
>>>
>>>
>>>
>>>
>>>
>>> As compared to what you'd expect (scale set to normal/100%):
>>>
>>>
>>>
>>>
>>>
>>> Very easy to reproduce the above, set your scale to 125% and run this:
>>>
>>>
>>>
>>> public class ToolbarBugApp extends Application {
>>>
>>>
>>> @Override
>>> public void start(Stage primaryStage) {
>>> BorderPane bp = new BorderPane();
>>> // Wrapping in HBox and using button with 13+ chars causes bug
>>> bp.setTop(new HBox(new ToolBar(new Button("Create Schema"))));
>>> // BUG
>>> // bp.setTop(new ToolBar(new Button("Create Schema"))); // NO BUG
>>> (no HBox)
>>> // bp.setTop(new HBox(new ToolBar(new Button("Create Schem"))));
>>> // NO BUG (12 chars)
>>> primaryStage.setScene(new Scene(bp, 600, 400));
>>> primaryStage.show();
>>> }
>>>
>>> public static void main(String[] args) {
>>> launch(args);
>>> }
>>> }
>>>
>>>
>>>
>>> As per the comments, this bug appears to happen when your ToolBar is
>>> wrapped in a HBox and contains a Button that has 13+ characters, for
>>> example. This is quite a serious bug, in my opinion.
>>>
>>>
>>>
>>> I believe this is present in JFX 24 and the JFX 25 master branch.
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>>
>>>
>>> *Cormac Redmond*
>>>
>>> Software Engineer, Certak Ltd.
>>>
>>>
>>>
>>> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 177920 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5287 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14011 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6945 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6634 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14019 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 23504 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 84813 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251221/f9c55777/image-0015.png>
More information about the openjfx-dev
mailing list