Issue with menu bars and menus

[io7m]

Hello!

I'm still having problems with what I believe is the simplest possible menu bar setup. See the following repro case:

https://github.com/io7m/fxmenubug-20190801

Just run "Main".

Here's a video of the issue, as it's fairly difficult to describe:

https://github.com/io7m/fxmenubug-20190801/blob/develop/capture.ogv

The gist is that it's fairly hard to open a menu: Clicking the menu header opens and closes the menu immediately, most of the time. If the menu does stay open, the menu itself is rendered in the wrong place (away from the menu bar). I reported this on the mailing list over a year ago and it was suggested that I try the GTK2 backend. This, I believe, worked around the issue but also had other issues that meant that I couldn't use GTK2 for the application I was building. I had hoped that this would have been fixed in the GTK3 backend by now, but evidently it hasn't.

Interestingly, on the exact same JVM (OpenJDK 11), same window manager (i3), and same version of JavaFX (13 EA 10), Gluon's SceneBuilder menus do not have this broken behaviour.

[io7m]

$ uname -a
Linux almond.int.arc7.info 5.1.16-arch1-1-ARCH #1 SMP PREEMPT Wed Jul 3 20:23:07 UTC 2019 x86_64 GNU/Linux

$ java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)```

[io7m]

On the same platform, but using OpenBox instead of i3 as the window manager, the problem just magically goes away.

I was tempted to view this as an i3 bug however JavaFX is the only UI package that seems to have issues on this system in i3. Is there more information I can give you that can help you track down what's going wrong when running under i3?

[matthjes]

I'm experiencing the same problem with JavaFX and i3. However, when I switch back to JDK 8 with the included JavaFX, then the menus work correctly.

[lbotano]

I have the same problem but with bspwm.

[AiyionPrime]

Well, GitHub was faster. Just wanted to let you know: I've got the same behavior.

OpenJDK14.0.2, i3 4.19, Linux 5.9.11-arch2-1

Thanks @io7m for providing the video. Have been searching for this for about an hour now, and not getting it reproduced properly was driving me nuts -.-'

[AiyionPrime]

Very well. I'm still testing various tiling window managers; but I made some progress.

What we've got here is a bug which is actually two. As soon as one understands the following the strange behaviour @io7m desribed

Clicking the menu header opens and closes the menu immediately, most of the time.

is reliable.

The thing about some tiling windowmanagers is, that they're removing the top bar which holds interesting stuff, like the applications logo, its title, as well as, e.g in windows, the minimize, fullscreen and close buttons. This is a rather rude concept of wm-developers, as getting rid of those bars is nothing application developers necessarily expect. The result is the first part of the bug. A javafx application as ours calculates the offsets for the menubar wrong. This firstly leads to a dropdown menu thats set of by about the height of the missing topbar; as well as a vastly decreased reliably clickable area in the menubar.

Means: the e.g. top 95% of the menubar-button don't keep the menu open, while the top 5% do.

Opening a reference java program with a javafx menu using only X can verify this, as it does not provide the top-bar of a program at all.

xinit java -jar exampleprogram.jar

This means, the issue is not even a tiling-wm issue, but only an issue for windowmanagers that crop the top bar, which is merely an overlapping quantity.

And finally we come to i3. i3 Is an even more messed up special snowflake, as it does like others crop away the top bar, but only to then attach its own one.

This means, while other twm have this strong ratio of 95 to 5% mentioned above, with i3 its more like 30 to 70%, which disguised the underlying bug pretty well. So, uncertainty gone.

Which finally leads to part two of the bug, which should now be easier to reproduce. The combination of javafx and i3 worked perfectly with gtk2, which means someone has taken these offset calculations into account, some time ago. And someone else? did not anymore with gtk3.

Whatever the solution to all this is, chances are these are two bugs, with the latter one being a regression bug... What a mess.

I hope this helps.

[xebcam]

Got the same problem with suckless dwm on java 15 and javafx 15

[jlangvand]

Same problem here.

$ uname -a
Linux joakilan-arch 5.11.15-arch1-2 #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +0000 x86_64 GNU/Linux

$ java -version
openjdk version "15.0.2" 2021-01-19
OpenJDK Runtime Environment (build 15.0.2+7)
OpenJDK 64-Bit Server VM (build 15.0.2+7, mixed mode)