Cannot move/rearrange panes when running under Wayland

Bug reports
, , , , ,
1

When running Obsidian natively under Wayland, it’s impossible to move panes or sidebar tabs.

Dragging them appears like it’s going to work by showing you where the new pane location will be, but when you release the mouse button the pane just stays in place.

Resizing and opening new panes works as expected.

The issue does not occur when running under XWayland. The only way that I can re-arrange my sidebar panes is to quit Obsidian, launch it under XWayland, move the panes to where I want them, and re-launch Obsidian back under Wayland.

I prefer to run under Wayland as performance is better and the UI looks crisper.

Screencast of the issue under Wayland, using the Sandbox Vault with default settings: http://cdn.maddison.io/PvoT2VFONK--2022-08-26_14-19-50_region.mp4

Obsidian: v0.15.9
OS: Arch Linux (Linux 5.18.18-xanmod1-1 GNU/Linux)
WM: Sway v1.7-9 (Wayland 1.21.0-1)
Graphics: AMD RX Vega 56
Electron: v18.3.6-1
13 Likes
2

Sorry, you have too much of an niche configuration for us to look into it.
Try the appimage installer with gnome or kde under wayland.

3

Have you tried forcing wayland mode with --enable-features=UseOzonePlatform --ozone-platform=wayland

4

Fedora Linux (36) on Gnome (42.4) with Wayland. Tested Obsidian Flatpak and AppImage, including with the provided flags.

Debug Info 
SYSTEM INFO:
	Obsidian version: v0.16.0
	Installer version: v0.15.9
	Operating system: #1 SMP PREEMPT_DYNAMIC Sun Aug 21 15:52:59 UTC 2022 5.18.19-200.fc36.x86_64
	Login status: logged in
	Catalyst license: supporter
	Insider build toggle: on
	Live preview: on
	Legacy editor: off
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:

none

With Obsidian pre 0.16.0 dragging worked fine inside a window. Meaning, one could drag panes to create splits. Dragging outside the window to create pop out windows didn’t work.

With Obsidian 0.16.0 dragging panes around doesn’t work at all.
Weird thing is, that dragging inside the file explorer to move files does work, and dragging them inside an editor (to create links) or into the header to open them did and does still work fine.

(Sorry for the strong compression artifacts)
Kooha-2022-08-29-22-59-38

1 Like
5

Have you tried forcing wayland mode with --enable-features=UseOzonePlatform --ozone-platform=wayland

Yes, that’s how I normally run Obsidian. The bug occurs when these flags are used, the bug does not occur without them (without the flags, XWayland is used).

6

Can confirm (I also just noticed that the community maintained flatpak already applies these flags)

7

Since there is no platform-specific code on our end, this is either a problem of chrome, electron, or wayland.

8

if you feel adventurous, you can tweak the custom arch package to use electron20 or electron21 and see if it helps.

9

Tested with electron20 and electron21 alpha, issue exists in both.

10

I will step through the code in the JS debugger and see if I can figure anything out.

11

Hey @maddi, I have the same problem, did you end up finding the solution or at least tracking down where the bug might be?

It’s kinda annoying to have to switch to XWayland every time I need to re-arrange tabs.

12

@SV337 This is still a problem for me. I never did come up with a workaround, other than to switch to xwayland as you mentioned.

From debugging the code, it seems to be an issue with the event handlers. Specifically, it seems like the drop event isn’t being fired. But take that with a grain of salt, because it’s difficult to follow the event handling control flow using the minified code.

13

I’ve got the same problem on Fedora 36, Wayland, Gnome and Flatpak distribution of Obsidian. The AppImage version works as expected.

There is a possible related bug in VSCode (or Electron). They mention that enabling the native title bar solves the issue. I tried to change the title bar in Obsidian (Options → Appearance → Window frame style) to native, but the title bar stays hidden.

1 Like
14

That is very interesting, and the best lead so far. Do you know what is different about the AppImage as opposed to the regular package or Flatpak? Is it using a different version of Electron?

15

Bumping this thread, as i have just run into this issue using flatpak version of obsidian on Fedora 37 KDE/Wayland, when trying to get setup (using a youtube guide) - in 26th February 2023.

It is really difficult when something suddenly does not work as i’m trying to follow along with a setup tutorial. Honestly, I dont really want to use the app image version, I just wish the flatpak would work, any ideas how to fix it?

I downloaded the App image and tested it, and can confirm the app image version works fine, but flatpak is broken!!!

no fixes yet?

1 Like
16

We don’t provide support for flatpak and arch packages because we don’t make them. That being said, this is likely a wayland or electron under wayland issue and we’ll wait for the upstream fix.

17

Why not install .deb?

18

I am using fedora.

19

How’re you running Obsidian? As far as I can tell, this issue occurs in both the appimage and flatpak when I try it. It seems to have more to do with whether Obsidian is launching under XWayland or Wayland:

$ ./Obsidian-1.1.15.AppImage \
   --enable-features=UseOzonePlatform,WaylandWindowDecorations \
   --ozone-platform=wayland

When launching under Wayland, pane rearrangement doesn’t work regardless of type of window frame style.

A proper fix may not be available until Obsidian rebases against a newer Electron version with Wayland improvements.

20

Hi jstone, you are right, I had a flatseal Environment variable for Obsidian set to enable Native wayland by having it set to

OBSIDIAN_USE_WAYLAND=1

Before hand, but once i changed it to:

OBSIDIAN_USE_WAYLAND=0

It started working. This is weird because wanting to use wayland on my system meant it should be all smoother and faster, but unfortunately it broke the obsidian app.

1 Like