Page MenuHome

Reading clipboard in API blocks keyboard input on some Linux systems
Closed, ResolvedPublic

Description

System Information
Operating system: Ubuntu 19.10
Graphics card: Nvidia 2060

Blender Version
Broken: 2.82
Worked: not sure if ever

Printing out the content of the clipboard from a timer blocks keyboard input after a while on linux.
basically all descriptions from T73507 can call the bug.

Exact steps for others to reproduce the error
Install the following max-stripped add-on, open some file, copy some text into your clipboard from anywhere, try to grab with G key objects around until you get stuck. Should happen after a few seconds.


I used this file provided by someone in T73507 to reproduce:

exact test 'addon' code:

import bpy

@bpy.app.handlers.persistent
def check_bug():
    print(bpy.context.window_manager.clipboard)
    return .01 # this value is quite extreme, it 'works' also with 0.1 but takes longer to take effect


def register():
    bpy.app.timers.register(check_bug, persistent=True)
}

Event Timeline

Vilem Duha (pildanovak) renamed this task from Reading clipboard blocks keyboard input on linux to Reading clipboard in API blocks keyboard input on linux.May 7 2020, 2:11 PM
Vilem Duha (pildanovak) updated the task description. (Show Details)

Thanks for finding the cause!

I don't think any application should automatically read the clipboard, it should only do so when prompted by a user action. That's a security issue. Imagine for example a user copies a password, and that then automatically gets sent to BlenderKit servers as a search query.

Still, this bug should be fixed of course.

We only detect very specific content of clipboard (a direct link to an asset in the database) - these get detected and searched for. Otherwise, clipboard content is ignored. Hope with this condition it is fine? Currently the string searched for in clipboard is 'asset_base_id:'. As far as I know, some other bridge addons (not in git) might monitor the clipboard for the input.

I was unable to replicate this issue many times under Ubuntu 19.10 with XFCE environment. Now I updated to 20.04 and start using Gnome and I am finally able to replicate this. So the bug probably occurs only under Gnome, or is sensitive to used environment.

I also tried several Blender versions and was able to replicate the bug: 2.80, 2.81a, 2.82a, 2.83-9605c2616696.

Also the keyboard lockdown happens with any keyboard input anywhere where I tied it (3D view, BlenderKit inputs, other inputs, alt/ctrl keys,...). So what probably only matters is that the press of key should come in some consequence to reading the bpy.context.window_manager.clipboard. When the reading or pressing keys occurs more often, the lockdown is more probable.

@Vilem Duha (pildanovak) I still think it's problematic with asset_base_id testing. If other add-ons do it, I think that's bad as well. Assuming that something that is on the clipboard is safe to send to a server is not ok in my opinion, even if it tests for a specific prefix.

Performance is also an issue. If some copies a big file to the clipboard, Blender operation will suddenly become slow.

Campbell Barton (campbellbarton) renamed this task from Reading clipboard in API blocks keyboard input on linux to Reading clipboard in API blocks keyboard input on some Linux systems.May 8 2020, 9:55 AM

What desktop environment are you using?

Testing with gnome and it's not happening on my system,
even with over 700kb of text in my clipboard I couldn't get Blender to hang.

It may be that this only happens when using a clipboard manager.

The clipboard code is calling XNextEvent to pop events from the queue. If there are non-clipboard events popped they would be lost.

We could go through the event queue for the clipboard, and then put back the events with XPutBackEvent so we can still process them later.

@Campbell Barton (campbellbarton) I am using Gnome on Wayland:

@Brecht Van Lommel (brecht) Would you consider safe enough to verify the string past the asset_base_id: to be valid UUID and the string past asset_type: to by valid asset type before querying the server?

Can be the performance issue be solved by reading only part of the clipboard like bpy.context.window_manager.clipboard[:200]?