Installer version is also v1.6.3
Can confirm I’m also still having this issue. Fedora. Installer version 1.6.5.
That’s interesting, maybe it’s because of an update in hyprland, since it is moving away from wlroots.
I just built the latest hyperland-git in Arch and loaded Obsidian (using Electron 28) in wayland mode.
I could not drag tabs around.
After a new setup of my system I also can’t any more drag and drop tabs 
I wonder what I had on my old system that enabled this functionality.
I’ve been trying to track down what’s going on with this for a little bit now, I’ll note, currently I can launch either the flatpak with --socket=wayland, or the /opt (debian from the source) obsidian with the proper flags namely --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations --enable-wayland-ime, when I do that I experience the bug where by I can not create new window panes via drag and drop, but oddly I can use the menu contexts and “spit right”/“split down”, or ctrl+n, ctrl+t for a new tab to mostly work around the bug.
This is literally the only major problem I have with obsidian right now. Love the product, can’t imagine living without it, can’t wait to get the updating version of the right libraries to run without this very specific wayland bug. Still presents years and years later with the same bug.
v1.6.5 on Debian stable using Wayland and sway.
1 Like
v1.6.7 apologies, sometimes we move so quick with those numbers!
I’m also running into this bug, and I’m unwilling to switch back to XWayland because of blurry text on my HiDPI screen. I understand it’s complicated to fix, but I would appreciate a keyboard shortcut to move the current tab left and right. Firefox has Ctrl+Shift+PgUp/PgDown for this. That would work in place of drag and drop for me!
2 Likes
2 years later, as what once was ‘too niche’ a configuration becomes more and more common, there is no fix in sight. There isn’t even a sign of an effort.
This does not appear to be an issue with chrome, not vs code, I downloaded both just to confirm this, and Tab rearrangement and drag and drop pane splitting work fine on both.
I’m getting around this using the command palette splitting and the new tab icon.
(Fedora 40, Plasma & Hyprland)
The tabs in chrome are not implemented using web technologies. They have their own ui. It depends on what you try to drag an drop and where. Refer to the vscode bug report linked above.
I don’t see a bug report but I tried to replicate the error using vs code and could not
1 Like
@jsphnecclia I’m using Fedora/wayland with the flatpak version of Obsidian and can drag tabs around with no issues. I recommend switching to this one. I haven’t experienced any odd issues with Obsidian on Fedora/wayland running it this way. Fonts look great, fractional scaling is perfect, dragging works as it should.
Well here is the issue from VSCode again (still open). It seems that they are more concerned with the dnd of sidebar elements not tabs. Dnd of tabs seems to work there somehow.
Are you running the faltpak version in native Wayland-mode or in XWayland? XWayland does not suffer the dnd problem but brings other trouble for some users.
XWayland, which is the package’s default, but that’s why I mention that everything is working perfectly so that you’d know there weren’t any other issues caused by that.
I’m a heavy user of most Obsidian features as I develop a number of plugins, and I have not noticed any issues at all.
Thanks for clarifying 
, I now also noticed that we talked about that here earlier. I’m going to have a look at the flatpak-version in XWayland mode then, because the normal AppImage and the package provided by the Arch repo does suffer from blurry text when using fractional scaling for me.
However for me that will still be more of a workaround than a real permanent solution, since more and more desktops are moving to wayland and native wayland support still seems to be more performant for some users.
1 Like
Given that when a tab or window is clicked-and-dragged, that obsidian responds by reacting to where the user is trying to drag the window, it would seem that the onus is indeed on Obsidian and not electron, as the app clearly is receiving the input but is not performing the action as intended.
This eternal excuse of “wayland isn’t there yet” or “no one uses wayland” in favor of defaulting to an effectively deprecated solution is lazy, and ultimately is just downright insulting, especially to those of us who have paid for the product for years. If obsidian weren’t closed source, I’d be happy to contribute my efforts towards this issue, but alas it isn’t. Which again, adds insult to injury when come by and laud this as some impossible effort.
Please, we love this software- some of us enough to pay for it- please for the love of god make things behave properly
2 Likes
We do not have special code for any os, or windows systems. We rely on the apis provider by electron/chrome which in turn use the os.
If the code we have works on win, macos, x11 and not on wayland, it’s wayland problem.
If you are a developer and want to contribute in fixing the problem please help the upstream projects electron/chrome/wayland.
If the code we have works on win, macos, x11 and not on wayland, it’s wayland problem.
On the other hand, if a bug is replicable on one piece of software, and you point to at least 3 other softwares and say “the bug is in these softwares instead”… but your community cannot even replicate the bug in those softwares, doesn’t it make sense to at least treat it like another bug. Even up to 16 hours ago you still were pointing at a completely unrelated bug (as the upstream error) on vs code as an excuse to not look seriously into this one, even though OP told you on August 31 (nearly a year ago) that “the bug affected obsidian and not VS”, which means to say explicitly, it was a separate error…
Which is to say, the bug isn’t related to the upstream bugs that you mention!
So if the code works on windows, macOS, and X11, and not wayland, seems like a wayland problem. But if you go through every app that supposedly has this same upstream problem and can’t personally replicate those bugs, it points to a bug on your side of things. So the right thing to do would be to try to fix that bug, see what comes about, even if you inadvertently happen to fix an upstream bug too?
This goes beyond arch and flatpak. Wayland adoption 2 years ago isn’t the way it is now. Wayland is quickly replacing X everywhere, and the “too niche” dismissal shuns a reasonably large portion of your community.
2 Likes
I have personally reproduced the problem on vscode.
The too niche comment was in relation to arch and a tiling window manager, not wayland itself. We do take bug reports in linux when obsidian is running gnome or kde and a major distro like Ubuntu or Fedora.
The code also works on mobile platforms (android and iOS, if you have a mouse attached)
I have seen a lot of activity upstream around this issue, so I am sure it will be solved.
I the meantime, xwayland.