Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flameshot freezes and becomes unresponsive when using "Copy to Clipboard" on KDE Wayland #3785

Open
admdanielspalma opened this issue Nov 17, 2024 · 9 comments
Labels
Unconfirmed Bug The bug is not confirmed by anyone else.

Comments

@admdanielspalma
Copy link

Flameshot Version

v12.1.0
Compiled with Qt 5.15.14

Installation Type

Linux, MacOS, or Windows Package manager (apt, pacman, eopkg, choco, brew, ...)

Operating System type and version

Arch Linux Kernel: 6.6.61-1-lts

Description

After updating my Arch Linux system between October 30 and November 2, 2024, Flameshot started freezing and becoming unresponsive when using the "Copy to Clipboard" feature on KDE Wayland.

I attempted to roll back several packages, including Qt libraries, and KDE components, but the issue persisted. Unfortunately, my knowledge of Linux is limited, and I may not have identified or reverted all relevant packages.

Details:

  • Taking a screenshot and saving it as a file works as expected.
  • Copying a screenshot to the clipboard makes Flameshot extremely slow (and doesnt copy). The interface appears to freeze for extended periods.
  • If another screenshot attempt is made while Flameshot is in this state, the interface opens multiple times, displays a "focus lost" message, and does not recover. Clicking as instructed to regain focus does not resolve the issue.
  • Right-clicking the system tray icon also becomes unresponsive (e.g., delays of 1 minute or more).
  • Restarting Flameshot is required to regain functionality.

Example log output:

qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
flameshot: error: Não foi possível capturar a tela (can't capture screen in portuguese)
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

The issue did not occur before this system update, and Flameshot was functioning perfectly on the same system with KDE Wayland.

Steps to reproduce

  1. Launch Flameshot on KDE Wayland.
  2. Take a screenshot using the "Capture" option.
  3. Choose "Copy to Clipboard" after capturing the screenshot.
  4. Observe the system slowdown or freezing behavior.
  5. Attempt to take another screenshot and observe the "focus lost" issue.

Screenshots or screen recordings

No response

System Information

Operating System and Version: Arch Linux, Kernel 6.6.61-1-lts
Monitor Configuration: Single monitor, 1920x1080 resolution
Desktop Environment: KDE Plasma 6.2.3
Window Manager: KWin
Display Protocol: Wayland

The issue only occurs when using Wayland; it did not happen in prior versions of the operating system.
Monitor configuration screenshot attached for reference (if applicable).

@admdanielspalma admdanielspalma added the Unconfirmed Bug The bug is not confirmed by anyone else. label Nov 17, 2024
@FelixJochems
Copy link

FelixJochems commented Nov 17, 2024

I'd have to setup a VM with Arch and KDE to fully test this, could you confirm that your XDG_CURRENT_DESKTOP environment variable is kde-plasma? KDE gets forced to the DBUS implementation which is rather unstable under wayland especially, since clipboard implementations are vastly different between X11 and Wayland.

As for what exactly triggered it between 30th and the second of november, I cannot say.

@admdanielspalma
Copy link
Author

admdanielspalma commented Nov 17, 2024

Here’s the updated information based on my tests:

Environment Variables:

  • XDG_SESSION_TYPE: wayland
  • XDG_CURRENT_DESKTOP: KDE

Clipboard Functionality:

I tested with Spectacle (KDE's screenshot tool), and the clipboard functionality worked perfectly under Wayland. This includes copying screenshots to the clipboard and subsequent operations. This suggests that the clipboard implementation in Wayland is functioning correctly for other applications.

Behavior in Flameshot:

Flameshot still exhibits the same issues when using the "Copy to Clipboard" feature. The freezing persists regardless of whether the XDG_CURRENT_DESKTOP variable is set to KDE or GNOME.

Debug logs were collected during these tests (see below).
Logs: Below are some relevant logs captured when Flameshot was running (QT_LOGGING_RULES="*.debug=true" flameshot)

...
qt.text.font.db: Adding font: familyName "Sans Serif" stylename "" weight 50 style QFont::StyleNormal pixelSize 0 antialiased true fixed false
qt.text.font.db: Adding font: familyName "Sans Serif" stylename "" weight 50 style QFont::StyleItalic pixelSize 0 antialiased true fixed false
qt.text.font.db: Adding font: familyName "Sans Serif" stylename "" weight 50 style QFont::StyleOblique pixelSize 0 antialiased true fixed false
qt.text.font.db: Adding font: familyName "Monospace" stylename "" weight 50 style QFont::StyleNormal pixelSize 0 antialiased true fixed true
qt.text.font.db: Adding font: familyName "Monospace" stylename "" weight 50 style QFont::StyleItalic pixelSize 0 antialiased true fixed true
qt.text.font.db: Adding font: familyName "Monospace" stylename "" weight 50 style QFont::StyleOblique pixelSize 0 antialiased true fixed true
qt.text.font.match: QFontDatabase::match
  request:
    family: Sans Serif [-- any --], script: 2
    weight: 50, style: 0
    stretch: 0
    pixelSize: 12
    pitch: *
qt.text.font.match:   REMARK: looking for best foundry for family 'Sans Serif' [1]
qt.text.font.match:           looking for matching style in foundry '-- none --' 3
qt.text.font.match:           best style has distance 0x0
qt.text.font.match:           found smoothly scalable font (12 pixels)
qt.text.font.match:           found a match: score 0 best score so far ffffffff
qt.text.font.match: QFontDatabase::match
  request:
    family: Noto Sans [-- any --], script: 2
    weight: 50, style: 0
    stretch: 0
    pixelSize: 12
    pitch: *
qt.text.font.match:   REMARK: looking for best foundry for family 'Noto Sans' [1]
qt.text.font.match:           looking for matching style in foundry 'GOOG' 12
qt.text.font.match:           best style has distance 0x0
qt.text.font.match:           found smoothly scalable font (12 pixels)
qt.text.font.match:           found a match: score 0 best score so far ffffffff
qt.text.font.match: returning box engine
qt.core.filesystemwatcher: adding ("/home/danielspalma/.config/flameshot/flameshot.ini")
qt.qpa.tray: D-Bus tray available: true
qt.qpa.tray: 
qt.qpa.tray: "Flameshot"
qt.qpa.menu: 1 "&Sair"
qt.qpa.menu: 1 "&Sair"
qt.qpa.menu: 2 ""
qt.qpa.menu: 2 ""
qt.qpa.menu: 3 "&Sobre"
qt.qpa.menu: 3 "&Sobre"
qt.qpa.menu: 4 "Verifique se há atualizações"
qt.qpa.menu: 4 "Verifique se há atualizações"
qt.qpa.menu: 5 ""
qt.qpa.menu: 5 ""
qt.qpa.menu: 6 "&Configuração"
qt.qpa.menu: 6 "&Configuração"
qt.qpa.menu: 7 ""
qt.qpa.menu: 7 ""
qt.qpa.menu: 8 "&Últimos Envios"
qt.qpa.menu: 8 "&Últimos Envios"
qt.qpa.menu: 9 ""
qt.qpa.menu: 9 ""
qt.qpa.menu: 10 "&Abrir Launcher"
qt.qpa.menu: 10 "&Abrir Launcher"
qt.qpa.menu: 11 "&Tirar Captura de Tela"
qt.qpa.menu: 11 "&Tirar Captura de Tela"
qt.qpa.tray: QDBusPlatformMenu(0x5dc7c8de5bb0)
qt.qpa.tray: "flameshot-tray" (QSize(24, 24), QSize(22, 22))
qt.qpa.tray: registering "org.kde.StatusNotifierItem-14417-1"
qt.qpa.menu: failed to register "org.kde.StatusNotifierItem-14417-1" "/MenuBar"
qt.qpa.tray: QDBusPlatformMenu(0x5dc7c8de5bb0)
qt.qpa.tray: "flameshot-tray" (QSize(24, 24), QSize(22, 22))
qt.qpa.tray: "Flameshot"
qt.qpa.menu: 0 depth 1 ()
qt.qpa.menu: 0 depth 1 () 0 QMap(("children-display", QVariant(QString, "submenu"))) revision 1 QDBusMenuLayoutItem(id=0, properties=QMap(("children-display", QVariant(QString, "submenu"))), 11 children)

This log was updated up to this point when launching the program. However, when attempting to capture the screen and copy to the clipboard, no additional lines were added to the log. In other words, during the issue, the log remained static and only reflects the initialization of Flameshot, without capturing any new activity in the terminal while the problem occurred.

Thank you very much @FelixJochems

@admdanielspalma
Copy link
Author

If you give me more instruction I may bring more logs or make a specific rollback to test so you doesnt need to run arch. Thanks.

@admdanielspalma
Copy link
Author

Now I was able to get more logs, i'll attach it. Thanks.

flameshot-debug.log

@FelixJochems
Copy link

Thanks a lot for the quick information.
Issue is that KDE always gets forced to the Dbus implementation of taking a screenshot, which evidently doesn't really work that well in Wayland.

The main takeaway for me is that we should just force the GRIM screenshot method whenever flameshot detects wayland and make WM specific implementations only when we have a stable and better implementation for said Window Manager.

@admdanielspalma
Copy link
Author

Thank you for the guidance earlier. Here’s an update on what I’ve tried:

Compiling Flameshot with Grim Support: I compiled Flameshot from source with Grim support enabled to test if it would resolve the issue. The steps I followed were:

mkdir build
cd build
cmake .. -DUSE_WAYLAND_GRIM=ON
make
sudo make install

Despite enabling Grim, the behavior remains the same when trying to copy a screenshot to the clipboard.

Testing on X11: I also logged into an X11 session to verify if the issue was specific to Wayland. Unfortunately, the exact same problem occurs under X11 as well, including the freezing and unresponsiveness when using "Copy to Clipboard."

Conclusion: Based on these tests, it seems the issue is not exclusive to Wayland or Grim support but might be related to Flameshot’s clipboard handling in general.

Let me know if you’d like additional logs or specific tests to narrow this down further.

@FelixJochems
Copy link

I was looking through the code and saw this piece of comment:

// If data is saved to the clipboard before the notification is sent via
// dbus, the application freezes.

So someone else must have ran into the same problem, I'm not a fan of setting the clipboard via DBus exactly because of these weird interactions. That same file has a half impemented KSystemClipboard. I'm sorry but this is just such a mess that I can better spend time on the fork I'm currently working on than sift through all this.

This does not take away from the fact that this is an exemplary bug report; You tried to eliminate some variables, have logs and described the circumstances under which this happens really well.

@admdanielspalma
Copy link
Author

admdanielspalma commented Nov 18, 2024 via email

@admdanielspalma
Copy link
Author

Up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unconfirmed Bug The bug is not confirmed by anyone else.
Projects
None yet
Development

No branches or pull requests

2 participants