Bug 274485 - XPRA/winswitch windows suffer from the default drag on all empty parts window dragging behaviour
Summary: XPRA/winswitch windows suffer from the default drag on all empty parts window...
Status: CLOSED FIXED
Alias: None
Product: Oxygen
Classification: Plasma
Component: gtk2-engine (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-30 00:30 UTC by armin.kazmi
Modified: 2015-05-23 09:26 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Xpra log section from winswitch when doing a window drag (5.35 KB, application/octet-stream)
2011-05-31 18:57 UTC, armin.kazmi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description armin.kazmi 2011-05-30 00:30:45 UTC
Version:           4.0 (using KDE 4.6.3) 
OS:                Linux

XPRA http://xpra.devloop.org.uk/ and further modified by http://winswitch.org/
is like VNC for only one application (simply put),its a xserver proxy using XVfb on the remote and therefore allows to transfer remotely running applications to the local display (with results similar to ssh x11 forwarding, but quite different in detail).

The problem is now, that xpra only displays a remotely running application and presents (apparently a GTK window), which is only a giant image of the remote application, without any markers from which oxygen and oxygen-gtk could extract info about real empty window parts. So this results in the whole window being considered empty, with the resulting behavior: Dragging is started everywhere in the window, on buttons, on scrollbars, simply everywhere.

xprop of an example application spawned using xpra over winswitch:
_NET_WM_ICON_GEOMETRY(CARDINAL) = 1135, 1053, 265, 29
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 23, 4
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 23, 4
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_STATE(ATOM) = 
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                window id # of group leader: 0x6400001
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 3052455
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 104857657
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x6400038
WM_CLIENT_LEADER(WINDOW): window id # 0x6400001
_NET_WM_PID(CARDINAL) = 5850
WM_LOCALE_NAME(STRING) = "C"
WM_CLIENT_MACHINE(STRING) = "PRIVATE"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified location: 0, 0
                program specified minimum size: 0 by 0
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "xfe", "Xfe"
WM_ICON_NAME(STRING) = "Xfe - /usr/home/PRIVATE  (on Freebsd)"
_NET_WM_ICON_NAME(UTF8_STRING) = "Xfe - /usr/home/PRIVATE  (on Freebsd)"
WM_NAME(STRING) = "Xfe - /usr/home/PRIVATE  (on Freebsd)"
_NET_WM_NAME(UTF8_STRING) = "Xfe - /usr/home/PRIVATE  (on Freebsd)"

It seems like xpra only exports the actual application name among with the machine name the application is running on, so no window class matching seems to be possible right now to apply workarounds for all windows matching a respective class.

Reproducible: Always
Comment 1 Hugo Pereira Da Costa 2011-05-30 00:58:47 UTC
Re-assigning to gtk style, if what's exposed is a gtk window.
Will investigate. 
Thanks for reporting and sorry for the trouble.
Comment 2 Hugo Pereira Da Costa 2011-05-30 10:00:20 UTC
@Armin
So far I have been unable to run xpra/winswitch myself so could not reproduce. 
Now maybe you could provide more information (assuming the application is using gtk as a backend).

Could you compile latest oxygen-gtk (from git trunk), with Debug mode enabled
(basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources)

And post here the log of the output, when running the application and after triggering one mouse-drag ? That should help be debug/blacklist.

Thanks,

Hugo

Sources from git are available via: git clone git://anongit.kde.org/oxygen-gtk
Comment 3 Antoine Martin 2011-05-31 16:52:32 UTC
Since the applications have their attributes forwarded, I doubt that you will be able to blacklist them as it is.
I think we may have to add a new window attribute via Xpra so that kde/oxygen can detect it and act accordingly (blacklist it or whatever).
Is there an existing attribute we can re-use, or can you suggest an attribute name we should use for that purpose? _NET_WM_XPRA?

"So far I have been unable to run xpra/winswitch myself so could not reproduce."
Would mind sharing the details?
Comment 4 Hugo Pereira Da Costa 2011-05-31 17:15:33 UTC
"So far I have been unable to run xpra/winswitch myself so could not
reproduce."
Missing python packages.

What about: 

"Could you compile latest oxygen-gtk (from git trunk), with Debug mode enabled
(basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources)"

Please ?
Only then might I be able to try figure out a fix.
Comment 5 Antoine Martin 2011-05-31 17:19:33 UTC
"basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources"
Sorry, *I* only have testing environments (via VirtualBox), so that's not an option for me.

Does the _NET_WM_XPRA sound reasonable to you?
It would catch all windows forwarded by xpra.
Comment 6 Hugo Pereira Da Costa 2011-05-31 17:20:49 UTC
"basically: cmake -DOXYGEN_DEBUG=1 /path/to/sources"
> Sorry, *I* only have testing environments (via VirtualBox), so that's not an
> option for me.
>
> Does the _NET_WM_XPRA sound reasonable to you?
> It would catch all windows forwarded by xpra.
>
Well I'd rather catch the native widget/window that runs locally and in 
which the app is embedded.
Comment 7 Antoine Martin 2011-05-31 17:23:36 UTC
Yes, that is *exactly* what I am proposing: the native widget window *is* xpra, and the contents of the window are just forwarded bitmaps of the real remote window's contents.
The applications that you launch via xpra have no idea that they are being remoted.
Comment 8 Hugo Pereira Da Costa 2011-05-31 17:24:35 UTC
listen, if you think you can fix the bug your way, feel free to submit a patch.
Otherwise, please let me try fix it my way. 
Thx.
Comment 9 Hugo Pereira Da Costa 2011-05-31 17:25:20 UTC
Saying it differently, I do not plan to check on X flags unless there is no other way, which so far has not been proven.
Comment 10 Antoine Martin 2011-05-31 17:44:26 UTC
let me see if I get this straight:
* you've never used xpra
* you don't understand what it does
* you don't like my proposed solution
* you are going to "fix it your way", which you won't be able to test since you don't use it

Am I missing something?
I don't mean to be argumentative here, I am trying to work *with* you to find a solution. I would submit a patch, but from the tone of your previous messages I get the strong impression that it would not be well received at all, so I will wait for now and simply tell users to "complain to KDE".
Comment 11 Hugo Pereira Da Costa 2011-05-31 17:46:54 UTC
> "I will wait for now and simply tell users to "complain to KDE"".

Please do,
Maybe some of them would be able to provide the information I need.
Comment 12 armin.kazmi 2011-05-31 18:57:27 UTC
Created attachment 60519 [details]
Xpra log section from winswitch when doing a window drag
Comment 13 Hugo Pereira Da Costa 2011-06-01 09:42:10 UTC
Hello Armin,
Thanks for the log.

To be sure I understand its content: is this the log of oxygen-gtk on the remote side, or on the local side (that runs xpra client ?)

If I understand bug 274623, xpra-client crashes (on the local side) when using oxygen-gtk. Correct ? If yes ? How did you get the log above ? 

Thanks for the info and patience. 
(I'm trying to figure out if the issue is on the local or on the remote side).
Comment 14 Nathaniel Smith 2012-04-13 21:50:13 UTC
Hi Hugo, 

Sorry for the rudeness above. I just happened to see this bug, and I might be able to help. IIUC, what's happening is that the gtk-oxygen style runs inside gtk+ programs and attempts to capture any clicks that occur outside of any widget, and for such clicks it triggers a drag?

That would make sense of the observed behavior. The xpra client acts like an ordinary gtk+ application, except a very minimal one. You can see the complete code for the windows that xpra opens here:
  https://xpra.org/trac/browser/trunk/src/xpra/client.py#L181

Basically, it just makes a subclass of GtkWindow which captures input events and draws directly on the window surface -- this window contains no widgets whatsoever. This is admittedly an unusual way to use Gtk+, and I can see how it might confuse things... nonetheless, it should probably be supported. It's also possible that this is a bug in xpra, where it's letting the default button-press-event handler run when it should be overridden, or something of that nature -- my memory of gtk+ signal chaining rules is rusty.

Antoine: If this analysis is correct, a possible hacky workaround would be to move the client window drawing code into a custom widget, and then place that widget inside the window. Also note that even if window matching were somehow appropriate for this bug, you are *not* allowed to just invent an attribute named _NET_WM_XPRA -- the _NET_WM prefix means "this is a standard attribute defined by the EWMH standard".

HTH.
Comment 15 Martin Vala 2012-04-23 20:30:22 UTC
Hi Antoine,

I would like to ask you. Is it possible to do, what Nathaniel is purposing? I would like to run xpra correctly in kde. 

Thanks for everything.

Ciao

Martin
Comment 16 Antoine Martin 2012-04-24 02:40:50 UTC
Hi Martin,

Although this "hacky workaround" sounds like it might do the trick, I am very reluctant to implement it as it would require some significant changes to the code, only to workaround an odd behaviour that is only present in kde/oxygen and nowhere else.

On the other hand, adding a window property (not named _NET_WM_XPRA but _XPRA_MANAGED or whatever kde would be happy with) would require one line of code on our side and probably little more than one line of code on the kde side...

Cheers
Antoine
Comment 17 Martin Vala 2012-04-25 07:30:00 UTC
Hi Hugo,

i am user who is complaining. I think i will be able to give you more info. Please just ask.

Will it be possible to implement what Antoine is writing in previous comment?

Thanks

Martin
Comment 18 Hugo Pereira Da Costa 2012-04-25 08:14:00 UTC
Hello Martin, others

What Nathaniel propose would work. I'd get the widget name, check and blacklist.

What Antoine propose would work, but requires that oxygen-gtk checks X Properties for every single window and every single application, just for this one application. X access being expensive, I will not implement that.

A third solution which I am working on implementing is to pre-define a GtkWidget (actually a GObject) property that oxygen-gtk could check in order to turn off grabbing. Accessing GObject properties is 
1/ much less expensive than accessing X windows
2/ as easy (or easier) to setup on the client side (the application) as an X property.
3/ the fact that the name of the property is defined (and hopefully will be documented) by the gtk-style makes it possible to be re-used by other applications with the same issue (or if you want, with which oxygen-gtk has the same issue).

The name of the property would be "_kde_no_window_grab", for consistency with oxygen-qt which already has such a mechanism in place (for QObjects)

Antoine ? Martin ? Does that sound acceptable ? 

Also, last but not least, 
the first thing oxygen-gtk does when checking if grab should be enabled on a gtk window is veryfying (before doing anything), if the GtkWindow has set the flags to receive Button Press and Button Release events, in which case grab is switched off, assuming that these events are indeed used by the window (and so unusable for oxygen-gtk's grab).

Namely (pseudo code): 

if( (gtk_widget_get_events ( widget ) & (GDK_BUTTON_PRESS_MASK|GDK_BUTTON_RELEASE_MASK) ) )
{ return false; } // means do nothing.

Why this fails here is either 
1/ because this mask is not set on the xpra GtkWindow
2/ the test above is done too early with respect to when it is set.
3/ there is a bug in my code (I'll try test this on my side with a simple dummy application)
Any comments on this ? (mostly 1/ or 2/)

Cheers,

Hugo

Reopening the bug report since there have been some activity lately.
Comment 19 Antoine Martin 2012-04-25 09:35:19 UTC
I'm quite happy to use gobject properties for "_kde_no_window_grab", that would be trivial to add. It would probably be worth having in any case, even if the event mask stuff can be made to work.

As for the event mask, we do this very early on in the gtk windows' constructor method:
WINDOW_EVENT_MASK = gdk.STRUCTURE_MASK | gdk.KEY_PRESS_MASK | gdk.KEY_RELEASE_MASK | gdk.POINTER_MOTION_MASK | gdk.BUTTON_PRESS_MASK | gdk.BUTTON_RELEASE_MASK

So I would have thought that the oxygen-gtk catch code should fire... I'll try to see if I can move it earlier in the constructor. Any idea when/how-early this catch is tested for?

Cheers
Antoine
Comment 20 Hugo Pereira Da Costa 2012-04-26 08:11:29 UTC
Hi Antoine,
From my test here, it should be sufficient to set the event mask _before_ calling gtk_widget_show( your_widget );

More explicitely:

  gtk_widget_add_events( widget, GDK_BUTTON_RELEASE_MASK |  GDK_BUTTON_PRESS_MASK  );
  gtk_widget_show( widget );

Can you test and possibly confirm that it fixes the bug ? 
I'm still working on implementing the gobject property handling (for completion), but in your case it should not be necessary.

Hugo
Comment 21 Antoine Martin 2012-04-26 08:36:03 UTC
That is already the case:
https://xpra.org/trac/browser/tags/v0.2.x/src/xpra/client.py#L1026

        window = ClientWindow(self, wid, x, y, w, h, metadata, override_redirect)
        (...)
        window.show_all()

We create the new ClientWindow (gtk.Window subclass) and we call show_all() after calling the constructor.
The constructor is here:
https://xpra.org/trac/browser/tags/v0.2.x/src/xpra/client.py#L204
and it contains:
        self.add_events(WINDOW_EVENT_MASK)
(with the WINDOW_EVENT_MASK value shown in comment:19)

There are no other calls to show() or realize() anywhere...
So I don't understand why this does not fire!
Comment 22 Hugo Pereira Da Costa 2012-04-26 08:49:59 UTC
ah ok. That's why it does not work.
The current check only work on "native" GtkWindow not on derived classes (because of other issues in other apps)
So this check will not work, sorry for the noise.

I could "blacklist" the derived class name (in fact that was my original idea).
The gobject property will work for sure also (when it is implemented in the oxygen-gtk code)
I expect to have something by the end of the week.
Comment 23 Hugo Pereira Da Costa 2012-04-26 11:19:52 UTC
Git commit 53312cd3dd5ae0338cc1c899f9461e82652cc9f8 by Hugo Pereira Da Costa.
Committed on 26/04/2012 at 13:13.
Pushed by hpereiradacosta into branch 'gtk3'.

added the same property names as for the Qt version in separate file.
check for _kde_no_window_grab property to blacklist widget.

M  +1    -0    src/CMakeLists.txt
A  +38   -0    src/oxygenpropertynames.cpp     [License: BSD X11 (BSD like)]
A  +46   -0    src/oxygenpropertynames.h     [License: BSD X11 (BSD like)]
M  +8    -0    src/oxygenwindowmanager.cpp

http://commits.kde.org/oxygen-gtk/53312cd3dd5ae0338cc1c899f9461e82652cc9f8
Comment 24 Hugo Pereira Da Costa 2012-04-26 11:24:35 UTC
Commits above would recognize setting the "_kde_no_window_grab" to disable window grab.
Explicit code would be:

add:
        g_object_set_data( G_OBJECT( your_widget ), "_kde_no_window_grab", (gpointer)1 );

before gtk_widget_show()

So far it is only merged to oxygen-gtk's master branche.
I'll merge with the release branche (1.2) in a couple of days after testing for regressions.

Next "stable" releases of oxygen-gtk are for May 15 or so.
In the meanwhile, would be awesome if someone could test using oxygen-gtk compiled from source.
Comment 25 Antoine Martin 2012-04-26 11:32:47 UTC
Added _kde_no_window_grab=1 to all xpra windows:
https://xpra.org/trac/changeset/773

I'm running Fedora 16, so I can test if someone tells me how to get this change into whatever oxygen version is shipped with Fedora ...
Otherwise, testing xpra is relatively simple, build it from trunk:
http://xpra.org/dev.html
Then run a session:
http://xpra.org/#get_started

Thanks!
Antoine
Comment 26 Martin Vala 2012-04-26 11:36:48 UTC
Hi All,

i am using gentoo. so i can even test master(trunk) version. of xpra and oxygen-gtk.

Ciao

Martin
Comment 27 Martin Vala 2012-04-26 12:16:29 UTC
i builded oxygen-gtk from kde overlay, here is ebuild
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=x11-themes/oxygen-gtk/oxygen-gtk-9999.ebuild;h=1bc72f4dcd7960ff3318f92b070dfa3c8b1dac94;hb=HEAD

and installed latest trunk of xpra
mvala@vala ~/trunk/src $ PYTHONPATH=./build/lib*:$PYTHONPATH xpra attach ssh:alike@pcalike01:100
alike@pcalike01's password: cannot import x11 bell bindings (will use gtk fallback) : No module named bindings
failed to use native get_modifier_mappings: No module named bindings
failed to get keyboard repeat rate: No module named bindings

Ciao

Martin
Comment 28 Antoine Martin 2012-04-26 16:40:59 UTC
Hi Martin,

Sorry about the wrong instructions in the INSTALL file, this is now fixed in:
https://xpra.org/trac/changeset/775

You need to use this tweaked python path when not installing globally (which I don't do very often):
PYTHONPATH=`ls -d install/lib*/python`:$PYTHONPATH ./install/bin/xpra

Cheers
Antoine
Comment 29 Martin Vala 2012-04-26 19:46:52 UTC
Hi Antoine and Hugo,
it is working nicely. I can press buttons and do any action with menu. 
Perfect. Thanks for fixing it.

Ciao
Martin
Comment 30 Hugo Pereira Da Costa 2012-04-26 19:48:36 UTC
Awesome ! Nice collaborative work !
So I guess it will be available after next release of xpra and oxygen-gtk.
Closing.

Thanks for posting the bug, and for insisting ;)
Comment 31 Antoine Martin 2015-05-23 08:48:39 UTC
Looks like this is broken in GTK3: set_data function got moved to gobject:
https://developer.gnome.org/pygtk/stable/class-gdkwindow.html#method-gdkwindow--set-user-data
And then removed completely:
https://bugzilla.gnome.org/show_bug.cgi?id=641944

Any ideas on how to make this work again with Python3 / GI ?
(skipping rant about how difficult it is to move to py3k even without the constant API breakage)
Comment 32 Ruslan Kabatsayev 2015-05-23 09:26:51 UTC
@Antoine
This bug report is about oxygen-gtk2. If you found a problem with oxygen-gtk3, it's another bug.
Now, oxygen-gtk3 has a shaky future, see https://bugzilla.gnome.org/show_bug.cgi?id=735211 . Dunno whether GTK team has removed GtkThemingEngine in GTK 3.16 yet or if not, whether they will do before GTK 4. Thus I'm not sure if fixing anything for GTK3 is worth it.