Toolbar drop down appears in wrong position on multi-screen setup.

[lucky4some]

Apache NetBeans version

Apache NetBeans 25

What happened

NB14 worked fine. However, in NB26, 22 if you have a 3 screen setup , 2 screens butting along the top row, and 1 screen central on the bottom row then put NB somewhere in the top left window. Now open the Tools menu. The drop down appears to calculate the drop down position to be somewhat to the right of where you would expect as if it was using the total width of all the screens to calculate where it should go. NB 14 works this out correctly. See the images. Program running on Ubuntu latest long term release.

Language / Project Type / NetBeans Component

Just started NB. No projects open.

How to reproduce

Just open in correct place.

Did this work correctly in an earlier version?

Apache NetBeans 21 or earlier

Operating System

Linux Ubuntu

JDK

JDK17

Apache NetBeans packaging

Apache NetBeans binary zip

Anything else

Not really. Put NB in the centre of the top 2 screens, such that it is at least 1/3 over the RHS screen and it works o.k. But less than 1/3 of NB on the RH screen and the drop down menu gets displaced.

Are you willing to submit a pull request?

No

[mbien]

interesting. I do most of my work on a dual screen setup too on linux and this never happened to me.

I suppose the display manager is wayland. Can you test on latest JDK 24?

[lucky4some]

Will do.

[DevCharly]

Could be a FlatLaf (or JDK) related problem.

Could you please download and run FlatScreenInfo.java (is a single-file program; no dependencies) and post the output here. It outputs your screen configuration (resolution, scaling, etc). Please use the same JDK that you use to run NetBeans. Thanks.

[lucky4some]

/usr/sbin/gdm3

[lucky4some]

run: Scale factors: 100% / 100% / 100% Java version: 11.0.11 Java vendor: AdoptOpenJDK

ID: :0.0 (main) Size: 1920 x 1200 / -1 Bit / 60 Hz Bounds: 1920 x 1200 / x 989 / y 1200 Insets: left 0 / right 0 / top 0 / bottom 0 Scale: 1.0

ID: :0.1 Size: 1920 x 1200 / -1 Bit / 60 Hz Bounds: 1920 x 1200 / x 1920 / y 0 Insets: left 0 / right 0 / top 0 / bottom 0 Scale: 1.0

ID: :0.2 Size: 1920 x 1200 / -1 Bit / 60 Hz Bounds: 1920 x 1200 / x 0 / y 0 Insets: left 1053 / right 0 / top 0 / bottom 0 Scale: 1.0

[lucky4some]

Sorry - need to check JDK

[lucky4some]

Using latest NB with JDK21

run: Scale factors: 100% / 100% / 100% Java version: 21.0.6 Java vendor: Eclipse Adoptium

ID: :0.0 (main) Size: 1920 x 1200 / -1 Bit / 60 Hz Bounds: 1920 x 1200 / x 989 / y 1200 Insets: left 0 / right 0 / top 0 / bottom 0 Scale: 1.0

ID: :0.1 Size: 1920 x 1200 / -1 Bit / 0 Hz Bounds: 1920 x 1200 / x 1920 / y 0 Insets: left 0 / right 0 / top 0 / bottom 0 Scale: 1.0

ID: :0.2 Size: 1920 x 1200 / -1 Bit / 0 Hz Bounds: 1920 x 1200 / x 0 / y 0 Insets: left 1053 / right 0 / top 0 / bottom 0 Scale: 1.0

[lucky4some]

First set of results was JVM 11 NB 14 2nd was JVM21 NB 26.

[lucky4some]

Just a thought. My screen numbers are 0=bottom single screen. 2 = top row right screen, 3 = top row left screen.

In your case where you have no problems, is your main screen top left and 2nd screen top right. ?

[DevCharly]

This is a bug in JDK. It reports wrong "screen insets" in some situations for multi-screen setups. left 1053 in your case is way too large. Should be left 70 (or similar).

"Screen insets" is the space used on main screen for dock and for top bar.

Here is an example for correct insets (left 70 and top 34 on main screen):

Scale factors:  100% / 100%
Java version:   17.0.2
Java vendor:    Oracle Corporation

ID:      :0.0 (main)
Size:    1920 x 1284 / -1 Bit / 60 Hz
Bounds:  1920 x 1284 / x 0 / y 0
Insets:  left 70 / right 0 / top 34 / bottom 0
Scale:   1.0

ID:      :0.1
Size:    3304 x 918 / -1 Bit / 0 Hz
Bounds:  3304 x 918 / x 1920 / y 0
Insets:  left 0 / right 0 / top 0 / bottom 0
Scale:   1.0

If main screen is centered below of secondary screen, the insets on main screen are zero (should be same as before) and left inset is 873 on second/top screen (should be 0):

Scale factors:  100% / 100%
Java version:   17.0.2
Java vendor:    Oracle Corporation

ID:      :0.0 (main)
Size:    1920 x 1260 / -1 Bit / 60 Hz
Bounds:  1920 x 1260 / x 803 / y 918
Insets:  left 0 / right 0 / top 0 / bottom 0
Scale:   1.0

ID:      :0.1
Size:    3304 x 918 / -1 Bit / 0 Hz
Bounds:  3304 x 918 / x 0 / y 0
Insets:  left 873 / right 0 / top 0 / bottom 0
Scale:   1.0

Another example (wrong top insets 273):

Scale factors:  100% / 100%
Java version:   17.0.2
Java vendor:    Oracle Corporation

ID:      :0.0 (main)
Size:    1920 x 1266 / -1 Bit / 60 Hz
Bounds:  1920 x 1266 / x 3306 / y 239
Insets:  left 0 / right 0 / top 0 / bottom 0
Scale:   1.0

ID:      :0.1
Size:    3304 x 918 / -1 Bit / 0 Hz
Bounds:  3304 x 918 / x 0 / y 0
Insets:  left 0 / right 0 / top 273 / bottom 0
Scale:   1.0

All values are from Ubuntu 24.10. Using latest Java 24 or 25-ea makes no difference.

FlatLaf uses screen insets in some places. E.g. to avoid that popups overlap dock or top bar.

Seems that I have to modify FlatLaf to ignore screen insets on Linux, at least on multi-screen setups...

As workaround you could:

• left align primary display 1 to display 3 in "Screen Display" settings
• use another L&F (Nimbus or Metal)
• use JetBrainsRuntime to run NetBeans because this always returns zero screen insets on multi-screen setups

[lucky4some]

or use JDK 11 and NB14.

[lucky4some]

Run under Windows on same physical setup... Quite a difference. Thank you.

// NB26 on Windows JDK17

run: Scale factors: 125% / 100% / 100% Java version: 17.0.1 Java vendor: Eclipse Adoptium

ID: \Display0 (main) Size: 1920 x 1200 / 32 Bit / 60 Hz Bounds: 1536 x 960 / x 0 / y 0 (scale -1.25) Insets: left 0 / right 0 / top 0 / bottom 48 Scale: 1.25

ID: \Display1 Size: 1920 x 1200 / 32 Bit / 60 Hz Bounds: 1920 x 1200 / x 932 / y -1200 Insets: left 0 / right 0 / top 0 / bottom 48 Scale: 1.0

ID: \Display2 Size: 1920 x 1200 / 32 Bit / 60 Hz Bounds: 1920 x 1200 / x -988 / y -1200 Insets: left 0 / right 0 / top 0 / bottom 48 Scale: 1.0

[mbien]

looks like @DevCharly was so nice and implemented a workaround in the FlatLaf lib. Going to target NB 27 so that we don't forget to bump the dependency in case it is released in time.

[gitdode]

Could I just ask if the following issue is related to this one?

Example scenario:

1. NetBeans 26 opened on laptop screen (Debian 13 with Wayland and KDE/Plasma) without external screen connected
2. Connect external screen extending display to the right, move NetBeans to that screen
3. Trigger a popup/tooltip

Result: Popup/tooltip is opened on left (laptop) screen, at the right edge. As if it wants to move to the right screen where NetBeans has moved, but it cannot pass the screen edge:

It can even happen, that the popup/tooltip opens on a screen that was disconnected, with the effect of being invisible.

I guess this is an unfortunate combination of toolkit, JDK and window management?

[mbien]

@DevCharly since I see that https://github.com/JFormDesigner/FlatLaf/commit/532697128771370c8d5ae2773e8eef8bf3855384 made it into FlatLAF, are there plans for an update release?

[DevCharly]

@DevCharly since I see that JFormDesigner/FlatLaf@5326971 made it into FlatLAF, are there plans for an update release?

@mbien sure, FlatLaf 3.6.1 is now available 😄

Could you please create a PR?

[mbien]

@DevCharly thanks for doing a release! Will try to create a PR later assuming nothing unexpected shows up while finishing up the javac 25 integration.

[mbien]

opened https://github.com/apache/netbeans/pull/8651

dev build of the PR for testing: https://github.com/apache/netbeans/actions/runs/16240138983/artifacts/3519219474

cc @lucky4some

[eirikbakke]

There was a somewhat similar OpenJDK bug on Windows a while back, but that one seems to have been fixed: https://bugs.openjdk.org/browse/JDK-8211999