Closed davterra closed 2 weeks ago
Could be related to https://bugs.openjdk.java.net/browse/JDK-8251240
There are two potential workarounds mentioned in that bug report - setting an environment variable first with export GDK_DISPLAY=1
or a Java system property -Djdk.gtk.version=2
at runtime. The latter can be done by editing the /sparrow
shell script when running from source e.g. ./gradlew run -Djdk.gtk.version=2
.
OK, thanks. I added the environment variable to my .bashrc and reloaded.
While the pull-down menus still do not stay open with a single click on a menu header, I now find that if I press and hold down the mouse button (either left or right button) on one of the menu headers, and then while continuing to hold the mouse button down, move the pointer down to the area between the menu bar and the top of the opened pull-down window, the window stays open when I release the mouse button and functions within that menu can be chosen, or I can then move the pointer over to one of the other menu headers and that header's window opens and stays open. I hope I'm expressing this in a way that makes sense. I can provide screenshots if necessary.
Thanks for the feedback. Unfortunately, ultimately this bug will need to be fixed in the upstream JavaFX libraries.
Can I ask what window manager is being used on the Debian VM?
Thanks for the feedback. Unfortunately, ultimately this bug will need to be fixed in the upstream JavaFX libraries.
Can I ask what window manager is being used on the Debian VM?
Sure....using XFCE, which is the default in Qubes
I have the same problem. I use the bspwm windows manager. Single click seems to cause the menu to open and close quickly. When I click and hold I get this:
I can keep the menu open by moving the mouse cursor into the gap between the menu bar and the menu, before releasing the mouse button. So I guess that's a workaround. The workarounds suggested in the JDK thread didn't work for me.
Looks like an upstream fix is required. In the meantime users can run export GDK_DISPLAY=1
. Not sure any changes are required in Sparrow?
Neither of these worked for me as per @davterra experience. Both adding the environment variable or adding the Java system property -Djdk.gtk.version=2
in the sparrow shell script doesn't change the behavior in XFCE on Debian. The only thing of note with the latter (reverting to GTK 2) is the GTK error in the terminal is resolved when accessing the menu.
Can confirm that @emmanuelrosa fix does work for now though.
I guess we'll need to wait for the upstream fix at some point.
-- bvs
I've posted a message to the upstream project: https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-November/032762.html
No responses to date though.
Thanks for the update. I did look to do that myself but seemed quite a pain to be able to get an account to post.
-- bvs
Just pinging to revive this, even though it still is a problem upstream, just would like to show interest. Emmanuel's tips are the most reliable so far, but it still breaks the flow of having that unique movement only for Sparrow.
System: Qubes R4.1, XFCE4.
It appears an upstream fix is being actively worked on: https://github.com/openjdk/jfx/pull/915
I have the same problem. I use the bspwm windows manager. Single click seems to cause the menu to open and close quickly. When I click and hold I get this:
I can keep the menu open by moving the mouse cursor into the gap between the menu bar and the menu, before releasing the mouse button. So I guess that's a workaround. The workarounds suggested in the JDK thread didn't work for me.
Thanks, that worked!
Just to confirm I have the same problem on xmonad
:
$ xmonad --version && X -version && ./result/bin/sparrow --version
xmonad 0.17.2
X.Org X Server 1.21.1.8
X Protocol Version 11, Revision 0
Current Operating System: Linux framie 6.3.3-JohnOS #1-NixOS SMP PREEMPT_DYNAMIC Wed May 17 12:02:08 UTC 2023 x86_64
Kernel command line: initrd=\efi\nixos\fic4dqnia1621za7cljmx8w9n2742vqq-initrd-linux-6.3.3-initrd.efi init=/nix/store/62amnwq7n2axsqa44b4r6b6y2q7wxpgc-nixos-system-framie-23.05.20230518.48a0fb7/init mem_sleep_default=deep nvme.noacpi=1 loglevel=4
Current version of pixman: 0.42.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Sparrow Wallet 1.7.6
I'm having the exact same experience as https://github.com/sparrowwallet/sparrow/issues/170#issuecomment-915911301 and https://github.com/sparrowwallet/sparrow/issues/170#issuecomment-1474866983 .
Noting that the fix mentioned previously has now been merged, and should be available in JavaFX 21 planned for a September release.
Haha, okay. So, in ~4-5 months we'll probably see this fixed, I guess. Does that sound about right?
Thanks for following up @craigraw .
I have this problem and also the small font problem
I realized that fixing the font problem with _JAVA_OPTIONS=-Dglass.gtk.uiScale=150%
also simplified the workaround because now instead of dragging the mouse into the "gap between the menu bar and the menu" it is sufficient to just click into the lower part of the menu item, for example below the text "File".
An update on this - JavaFX 21 has been released, which may fix this issue. However, this version requires macOS 11 or GTK 3.8 or later, which means in particular discontinuing support for older 10.13 macs that cannot be upgraded beyond that version. From past issues I know there are still surprisingly quite a few users using these old machines.
That said, this upgrade will happen, and those users can continue to use older versions of Sparrow.
I have tried to run Sparrow with OpenJDK 21 inside a Fedora VM, and found out that the issue is still present, and then thought that using JDK 21 may not necessarily imply that I was using JavaFX 21. How do ensure/verify that JavaFX 21 is in use when running Sparrow? Also, I realized that according to this it may work with JDK 18.
Answering my own question because I overlooked that JavaFX is a dependency and the version can be changed to 21
in the corresponding place.
After doing that the issue is gone, and the gaps are gone too, so it looks and feels great, this is a screenshot of Sparrow running on JDK 21 + JavaFX 21.
@vlad-timofeev thank you, this is good feedback!
Planning this upgrade for next year.
For anyone interested in a workaround until the problem is fixed: Pressing the Alt Key and then the arrow keys makes the menus usabale with the keyboard.
I can also confirm that simply bumping JavaFX version to 21 like @vlad-timofeev did fixes the problem. Also, don't assign negative coordinates to monitors in Wayland like I did. It messes up the programs running in xwayland (like Sparrow) thanks to this bug: https://github.com/swaywm/sway/wiki#mouse-events-clicking-scrolling-arent-working-on-some-of-my-workspaces https://gitlab.freedesktop.org/xorg/xserver/-/issues/899
Sparrow has upgraded to JavaFX 22 in 49573d107578af4c4ff2004b75a82fb487316694.
A full set of (pre) release binaries has been prepared at https://github.com/craigraw/beta/releases/tag/1.9.2-javafx-22. Testing is appreciated!
Works well on my Gentoo workstation!
gui-wm/sway-1.9-r1::gentoo was built with the following:
USE="X filecaps man swaybar swaynag wallpapers -tray" ABI_X86="(64)"
x11-base/xwayland-24.1.2::gentoo was built with the following:
USE="-libei (-selinux) -systemd -test -unwind -xcsecurity" ABI_X86="(64)"
I run Sway with xwayland, no desktop environment.
https://github.com/user-attachments/assets/f5ff79c5-f3ff-4861-ac60-2f82987d744c
Confirm that now works as intended on a gentoo machine with dwl wm (wlroots-0.19 & xwayland) and opejdk-24.
EDIT: The drop-down menu works great but theres a new bug, not present in 1.9.1 on the same machine (tested also with different version of openjdk to make sure is a sparrow related problem):
If a wallet is saved with PASSWORD AND the "open most recent wallet" flag is set to "on" THEN last sparrow 1.9.2 beta CRASHES on every startup, freezing on the main screen without asking for password. Sparrow at this point remain freezed on screen and isnt responsive to any click and is even impossible to close (need to force-kill the processes related). It's most probably a conflict with the password little screen, it doesnt appear at all, it seems a sort of race condition. If NO PASSWORD is set AND the "open most recent wallet" flag is set to "on" THEN the wallet starts without problems. If a PASSWORD for a wallet is set, BUT the "open most recent wallet" flag is "off" THEN sparrow starts without problems. At this point is possible to manually open the wallet with password and the "password screen" will appear correctly on screen.
Apart from this that seems an isolated regression, last 1.9.2 beta seems to work fine in all the other situations tested for now.
@pony-montana Thanks for the testing. Can I confirm whether you are running the binary from the link above or from source (with an early access OpenJDK 24 build)? If you are running the binary, Sparrow is using it's own JRE, which for the 1.9.2 beta is Java 22.0.2.
I can't reproduce this on any of my Linux test systems on both Gnome and KDE, so I suspect it might be related to the wm. I'm unfamiliar with dwl - what would be simplest way to test on it?
In terms of debugging:
~/.sparrow/sparrow.log
?kill -3 <PID>
? This would normally trigger a thread dump which can be helpful to find a deadlock.@craigraw Hi, I'm running the prebuilt binary from beta and it is using correctly his own jre, I runned it on java openjdk 24 and openjdk 21 with exactly same results. Running sparrow with trace level debug I see some "resize to 0 x 0" that seems suspect, heres the log: sparrow.log
EDIT: The problem seems actually that the password-prompt popup screen is "resized to 0". If I type the password of the wallet and press enter while the screen is freezed on this view ---> then the wallet will load, sparrow will un-freeze and then will act correctly.
dwl (code here: https://codeberg.org/dwl/dwl)
@pony-montana Although I still can't recreate the issue, I've attempted a fix in 31f28712.
Can you try the new binary at https://github.com/craigraw/beta/releases/tag/1.9.2-dialog-fix?
@craigraw unfortunately same issue is still present in 1.9.2-dialog-fix
On Sway Sparrow sparrow-1.9.2-javafx-22
starts up as floating window (sized so its covers entire screen) it seems. The password prompt screen is also floating and gets covered by the main screen. If i press Shift+Mod+Space
, full-screen/floating toggle for Sway, the password screen appears and after filling it everything is responsive.
$ swaymsg -t get_tree
#1: root "root"
#2147483647: output "__i3"
#2147483646: workspace "__i3_scratch"
#3: output "DP-2"
#4: workspace "1"
#41: floating_con "Wallet Password - trezor" (xwayland, pid: 12885, instance: "Sparrow", class: "Sparrow", X11 window: 0x600017)
#42: floating_con "Sparrow" (xwayland, pid: 12885, instance: "Sparrow", class: "Sparrow", X11 window: 0x600003)
#40: workspace "2"
#5: con "Pull-down menus dont work when running in Debian 10 vm within Qubes · Issue #170 · sparrowwallet/sparrow — Mozilla Firefox" (xdg_shell, pid: 2139, app_id: "firefox")
This confirms it. I don't know about dwl. Probably something similar is going on.
I managed to reproduce this, and after many attempts have opted to solve it by introducing a delay before opening any dialogs on startup. Unfortunately, Wayland seems to have the behaviour of showing windows in the order they are fully rendered, not in the order they are programmatically shown. This means simpler windows show before more complex ones regardless of the application developers intent.
I've created a set of test binaries here: https://github.com/craigraw/beta/releases/tag/1.9.2-wayland-delay
@craigraw the issue is now solved on my machine with 1.9.2-wayland-delay!
I found another misbehaviour in my configuration: when sparrow is explicitely set in fullscreen mode, then the drop-down menu doesnt appear at screen and it is hidden behind the sparrow mainscreen.
@pony-montana Great, thanks for testing.
I found another misbehaviour in my configuration: when sparrow is explicitely set in fullscreen mode, then the drop-down menu doesnt appear at screen and it is hidden behind the sparrow mainscreen.
I couldn't reproduce this in Sway (using Mod+F
to toggle fullscreen). Maybe a dwl issue? Either way, this is not something I can do much about - it's on a lower level.
Works well! On my Sway setup, the drop-downs appear like they should, even when full-screen is toggled with Mod+f
.
Sparrow v2.0.0 has been released, so I'm closing this off. Thanks for all the help.
I am currently running v1.4.3 but this issue predates this latest release.
When I launch Sparrow in a Debian 10 vm running in Qubes OS, the pull-down menus do not stay open. I can click on a menu header and see the pull-down list of options for that header, but if I attempt to click on an option within any menu, the pull-down menu closes. I have tried clicking on a menu header and, keeping my finger on the mouse, moving the cursor down to the option I want, but that doesnt work either. The menu closes with no action. As a result, the only functions I can run are the few that have key-combination activators, e.g. Ctrl-O to open a wallet.