Drag & Arrows not working in canvas (Linux, AppImage, X11) on virtualbox

Bug graveyard
1

Steps to reproduce

  1. Create a new Vault
  2. Create a new canvas
  3. Create a new Card or Note
  4. Try to Drag the note around or create an arrow from it

Expected result

The Card moves or the Arrow gets created

Actual result

Nothing.

Environment

SYSTEM INFO:
Obsidian version: v1.1.16
Installer version: v1.1.16
Operating system: #1 SMP PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05) 6.1.0-6-amd64
Login status: logged in
Catalyst license: insider
Insider build toggle: on
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

Additional information

output

1 Like
2

What is your mouse do exactly?

3

I’m trying to drag the cards when the hand is visible and I’m trying to “Pull” from one of the dots on the corner to get an arrow. Both isnt working.

4

Sorry I meant what type of mouse do you have exactly?

5

Its the default pointer device of virtualbox.

I’ve made you another Video which shows the mouse keys:
output

6 
❯ xinput 
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VirtualBox mouse integration              id=9    [slave  pointer  (2)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse           id=11   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Sleep Button                              id=7    [slave  keyboard (3)]
    ↳ Video Bus                                 id=8    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=10   [slave  keyboard (3)]
7

Ok, this is new information. does it happen in a real system?

8

I’ve just checked on a different linux desktop (I only use my company computer these days, which forces me to use virtual box or my android tablet) and it works indeed. So I guess it has something to do with either the vbox pointer device or the virtual graphics device.

9
10
11

If the problem is due to virtualbox (more broadly the way the mouse events are generated under this virtual environment), we are not going to look into it (Obsidian code is platform agnostic and we intend to keep it that way).

My advise is to Google into virtualbox drag and drop problems or try another virtual environment.

12

Oh that’s a shame. It means that I cannot use it on my work machine because I have no control over the hypervisor or it’s settings.

13

@WhiteNoise, what is odd is that Obsidian is the only application I experience such issues. Neither native apps nor electron/browser-based ones exhibit such issues. Even drag & drop within other parts of obsidian (file explorer, excalidraw) and across apps works flawlessly. It’s just the canvas plugin that does not work.

The results of your linked search are also not really helpful because they describe issues of a VBox feature where you can drag & drop between VM and Host - this is disabled anyway.

For a bit of context: We have a corporate solution where you get your device with a locked-down Linux which ensures that all data written to disk is encrypted, and all network traffic goes through a VPN. Your “Workspace” is then a virtual machine on top of this system. There is nothing I can change on the host part of this setup.

14

I’ve tried to debug this on the xinput level and discovered two differences between a vbpx pointer and a real one:

  • The VBox pointer seems to not generate XI2 press/release events
  • The VBox pointer operates with abolute positions rather than relative.
15

Ah, there are actually two pointer devices provided by vbox:

❯ xinput            
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse           id=11   [slave  pointer  (2)]
⎜   ↳ VirtualBox mouse integration              id=9    [slave  pointer  (2)]

The first (id 11) is the one, producing the button press/release events. The second one (id 9) is the one producing the move events with absolute coordinates. If I run xinput test-xi2 2 (on the “virtual core pointer”) though, I get the very same behavior as with a “real” mouse on a “real” system - except that I get absolute coordinates rather than movement offsets.

To check this further, I used an old wacom tablet on a bare-metal session (which also emits absolute coordinates). It did not show any issues. I even realized, that also on this device there are two build-in pointers - the trackball and the touchpad. So even there, the events (clock & movement) can come from different slave devices - and it worked.

So, I’m really out of ideas and don’t know how I could debug this any further.

I guess this means no canvas for me then?

16

See Canvas Cards Drag and Drop Linux/ChromeOS - #8 by phil31753

17

I am facing the same issue as well. In the Obsidian source code, there is a condition "mouse" === e.pointerType which is not working as expected in Electron on Linux. The pointerType is being recognized as ‘pen’ instead of ‘mouse’, causing it to not work properly. Now that I understand the underlying reason, I am unable to find a solution. I’m not sure if this information can provide you with any new insights.

1 Like
18

Same on Ubuntu 22.04LTS with all updates as of today, fails on both Wayland and X.

19

Maybe this helps as it shows some info when starting from the UBUNTU prompt:

$ obsidian

2023-06-06 21:13:25 Loading main app package /snap/obsidian/12/resources/obsidian.asar

2023-06-06 21:13:25 Checking for update using Github

2023-06-06 21:13:25 Success.

2023-06-06 21:13:25 Latest version is 1.3.5

2023-06-06 21:13:25 App is up to date.

libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)

[214525:0606/171325.743989:ERROR:command_buffer_proxy_impl.cc(128)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer.

20

The key issue here is that Electron retrieves the pointerType as “pen” on certain Linux systems, which might be an upstream problem. On Firefox, I obtained the pointerType as “mouse”. The reason for the inability to drag is due to the code in Obsidian that includes the following condition: e.targetNode === this.wrapperEl && "mouse" === e.pointerType && 0 === e.button. You can find this in the debugged app.js:formatted file around line 110708. I am unsure whether making compatibility changes in the program will introduce new issues.

Arch Linux x86_64
Host: VMware20,1 None