Permanent input freeze when dragging blocks on KDE Plasma Wayland
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- electron, linux
- Domain
- desktop, operating-systems
Research direction
No source file or test entry point is named. First reproduce the drag-and-drop freeze on KDE Plasma Wayland using the listed steps, then inspect the Electron/Wayland input path and compare it with the linked Electron issue. Done means block dragging remains responsive on Wayland, including drops over the sidebar, while the existing X11 workaround still behaves as described.
Written by the indexing model from the issue text.
Description
Search first
- I searched and no similar issues were found
What Happened?
When dragging blocks in Logseq OG on KDE Plasma Wayland, the application becomes permanently unresponsive to keyboard and mouse input. The window remains visually responsive and can still be moved/resized by the window manager, but all input events (clicks, keyboard) fail to reach the application. The freeze is permanent and the process must be killed via SIGTERM or killall to recover.
This issue is consistently reproducible when dragging blocks over the left sidebar. Additionally, the freeze can occur during drag operations within the content area without approaching the sidebar, though this happens infrequently. The frequency of the latter case may increase with larger or more deeply nested blocks.
What continues to work during the freeze:
- Window rendering (visual updates continue)
- Window manager operations (resize, move, minimize/maximize)
- Mouse wheel scrolling
What stops working:
- Keyboard input
- Mouse clicks
- Any other user input besides scrolling
Reproduce the Bug
Most reliable method (dragging over the sidebar):
- Start Logseq OG on KDE Plasma Wayland (AppImage or ZIP package)
- Create a simple block or use any block from the default journal
- Click and hold on the block's bullet point (drag handle)
- Drag the block toward the left sidebar
- Release the mouse button while the block is over/near the sidebar
- Freeze occurs - application becomes permanently unresponsive
Alternative method (dragging within content area, less frequent):
The freeze can also occur during drag operations within the content area without moving toward the sidebar, though this happens infrequently. The frequency of this case may increase with larger or more deeply nested blocks.
See attached videos:
Sidebar.mp4: Most reliable reproduction (dragging block over sidebar)Random.mp4: Less frequent case (dragging in content area without sidebar approach)
Expected Behavior
The block should be moved to the new location without any input freeze. The application should remain responsive to keyboard and mouse input at all times or give the user some indication in case some processing is needed (e.g. when moving a large block with many deeply nested childs).
Screenshots
Consistent way to reproduce
https://github.com/user-attachments/assets/3d50dcff-11d9-456d-9a97-19b69312ba9f
- Dragging a block directly over the left sidebar
- Application freeze occurring upon drop
- Mouse wheel scrolling still working (proving it is not a complete input lock)
Less frequent case
https://github.com/user-attachments/assets/71d4cd90-d12b-4a99-bcb4-29237767c887
- Dragging within content area without approaching sidebar
- Freeze occurring during drag/drop operations
Desktop or Mobile Platform Information
Operating System: Fedora Linux 44
KDE Plasma Version: 6.7.2 (Wayland)
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 7.1.3-200.fc44.x86_64 (64-bit)
Graphics Platform: Wayland
Graphics Processor: AMD Radeon RX 9070
Logseq OG Version: v1.0.0
Package Type: AppImage and ZIP package
Additional Context
Browser Version (https://demo.logseq.com/) seems unaffected.
Workaround
Run Logseq OG with the X11 backend instead of Wayland:
# AppImage
./Logseq-OG-linux-x64-1.0.0.AppImage --ozone-platform=x11
# ZIP Package
./Logseq-OG --ozone-platform=x11
With this flag:
- All drag-and-drop operations work normally
- No input freeze occurs
- Application remains fully responsive
- Wrong Mouse Courser Icon while dragging
https://github.com/user-attachments/assets/42078f11-9f49-4b50-a483-d2e6c79885cd
Other findings
I've come across https://github.com/electron/electron/issues/49907, which might be related.
Conclusion
If additional information is required, I'll happy to provide it.
Are you willing to submit a PR? If you know how to fix the bug.
- I'm willing to submit a PR (Thank you!)
- Dominant language
- Clojure
- Stars
- 297
- Forks
- 52
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from logseq/og
-
Difficulty 4/5 3-5 days Newbie friendliness 62/100
-
Difficulty 3/5 1-2 days Newbie friendliness 76/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
.Team/Metabot Priority:P3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
needs triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
scalar-labs/scalar-jepsen#222 · 1 comment ·