Cannot move/rearrange panes when running under Wayland

I have personally reproduced the problem in Obsidian, while not being able to reproduce the problem on VSCode, the same for many others in this thread. This would heavily suggest that the errors are not the same.

I run KDE Plasma on Fedora (as well as Hyprland)
(If there is any other applications this would effect that I could test, lmk)

In the meantime I’m going to be using the command palette and the new tab icon. That works fine for me. Drag and drop would be better but whatever. I’m just shocked that this bug is 2 years old and the only thing that’s occurred so far is pointing the blame.

1 Like

This may work for the shrinking audience of low DPI users, but it has already been confirmed by many users with modern monitor resolutions as being illegible.

I run high-DPI monitors with whole and fractional scaling, and have zero issues running Obsidian from the flatpak.

I’m not saying there isn’t a bug to be resolved, but I am saying that using the flatpak from the store is working perfectly as a workaround on Wayland.

That is not necessarily how bugs work, especially in Electron. Electron, especially Electron+Wayland constantly has reoccurring issues that occur in one app but not another, get fixed for some but not all users of an app, regress 2 years later … this is the nature of the Electron beast. People will point to Chromium working, but they often implement a lot of stuff independently of electron. People will point to other apps working, but that is usually luck of the draw on your system or a result of hard coded platform specific fixes, or cherry-picked git commits fixing it for at least some people in some conditions. A project with a tiny dev team like Obsidian cannot commit to using hand crafted electron versions or platform specific workarounds.

This bug does exist for some Linux VSCode users too - as much as people claim otherwise. It also doesn’t exist for some Linux Obsidian users. Sure, it seems to occur less in VSCode than Obsidian, but thats not really a reflection of a bug in Obsidian. Its a reflection of VSCode apply the typical electron partial fixes more quickly, or of just happening to hit whatever reproducibility requirements the bug has less often. Based on this being “fixed” before, its likely actually several bugs breaking the same feature.

I understand this ordeal is frustrating but well, Electron is frustrating. Unfortunately, its what we have.

1 Like

If chromium is implementing stuff outside of electron, wouldn’t that imply that the fix is outside of electron? Even if electron can’t handle the user interaction (it can, I’m tired of this argument and the childish blame game), it’s not like you couldn’t implement keyboard controls to handle it. If I only had one hand and didn’t have the ability to use a mouse, would the dev response still be to kick rocks? Like, I know working with wayland can be a pain sometimes- I manage a hundred users daily that have to interact and develop on it. But we make it work, and it’s not even what we’re paid to do.

As for having dependencies that cause bugs (that are fixable), just fix them. It’s the whining and complaining and refusal to even acknowledge that it could even possibly be an issue on obsidians side that is absolutely infuriating. Like, just touch the damn thing, and give us an update! Like poke it, even. Just take a look and tell us why you, obsidian devs, can’t fix it. You would satiate the majority of angry users if you gave updates about it. Or hell, even open source the part of it that doesn’t work, let us fix it. It’s not a hard problem to solve, if the goal were to actually solve it.

You know what a wayland issue outside of your control looks like? Use a lenovo thunderbolt dock and disconnect it. That ain’t this, and this ain’t it.

Do better.

1 Like

This has been driving me nuts as well. I’m using Wayland compositors (Hyprland/KDE/GNOME) with:

obsidian --enable-features=UseOzonePlatform --ozone-platform=wayland

XWayland is fine but with horrible font handling, and using Ozone doesn’t work.

Firing up the developer console and executing:

monitorEvents(window,['pointerout'])

Shows that on Xorg/Xwayland, a final pointerout event is fired off when the tab being dragged is dropped (pointerevent buttons shows 1) to the desired location. On Wayland the pointerout event on releasing the mouse button never fires when the button is released.

This would lead me to believe that with the version of electron that I’m using with Obsidian v1.7.3 (electron 30.1.2) is not providing the event that Obsidian needs for it to trigger a tab drag/drop action.

Obsidian would have to make a poor guess that a user under Wayland that performs actions resulting in the following events intends a tab to be moved:

mousedown
mousemove
pointercancel
...
pointerout (happens during next mouse movement with buttons: 0)

This would just be a guess on Obsidian’s part and would not make the ui run as the user expects. So again, I believe this would be a bug that Obsidian should send to electron folks or see if the issue is fixed in a newer version of it.

1 Like

As an update, vscode’s electron console is similar; perhaps it is handled at a lower level in electron. Or I’m ignorant and misguided on how these events are handled.

1 Like

Update 2.

It looks like Obsidian is relying on the “drop” event to handle dragging the leafs of the ui. For whatever reason the drop event doesn’t fire under Wayland.

I think vscode relies on dragstart and dragend events only which do fire under wayland, hence the reason its tabs work.

If Obsidian were to use dragend as the event for moving a leaf/tab, it could fix the issue.

Throwing this code into the console, and running it once under Xorg/Xwayland will show all three events during a tab drag. (dragstart, drop, dragend) Running on wayland only dragstart and dragend will fire off.

function printEvent(e){
  console.log("EVENT: ", e);
}
window.addEventListener("drop", printEvent);
window.addEventListener("dragstart", printEvent);
window.addEventListener("dragend", printEvent);

I didn’t want to muck around too much in the debugger with app.js, but if dragend was used similarly to drop under wayland, I think the issue could be resolved.

4 Likes

Hello everyone,

We are testing internally electron v32 and this issue seems to be solved with it.

If there are no regressions, we will make a public build with it in the next weeks.
I’ll post a update in this thread when that happens.

10 Likes

Obsidian 1.7.5 comes with Electron 32. You will need to download and reinstall Obsidian from our website.

3 Likes

As far as I can tell this issue finally got fixed with electron v32 and the updated obsidian Version, at least for me. Thank you for the long and tiresome journey.

1 Like

Thank you very much for the effort.Moving the documents to side by side pane etc works now.

However, I still cannot move it out to create a new window. Moving only works within the already existing windows. So if I manually create a new windows, via right click, and move to new window, I can drag other documents into this.

But I can not create a new window by just moving a document out of the main window, as it is possible with X11 :slight_smile:

1 Like

This has fixed the specific problem! However it may have been the source of a new problem? When using the options Appearance > Advanced > Window frame style = Native frame I can no longer resize the obsidian window (hover mouse on the the edge of the window to resize). Moving the window by dragging the top bar of the window still works just resize does not ). I am on gnome+fedora 40 and normally the cursor icon changes but in this case it does not. Changing the window frame style to Hidden or Obsidian frame does allow resizing of the window. And I can resize the window using keyboard shortcuts or dragging the window to one of my screen corners/edges.

This is using Obsidian 1.7.5.

This is also an isssue on VSCode 1.95.1, and there is some talk of this in the electron community here

I have discovered two workarounds.

Option 1.
Super+right click > Resize
or Ctrl+F8

Option 2.
Change to Hidden or Obsidian frame

Thank you for the kind work WhiteNoise, Wayland now works perfectly for me! Even fixed a few bugs I realise now I forgot to report :flushed:. Thank you Obsidian team!

Thank you WhiteNoise. The latest installer fixed this issue and the ‘drop’ event is showing up in the console. yay!

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.