On Wed, Mar 01, 2017 at 08:45:36PM +0100, Dominik Vogt wrote: > On Wed, Mar 01, 2017 at 08:36:58PM +0100, Dominik Vogt wrote: > > On Wed, Mar 01, 2017 at 01:36:52PM -0500, Chris Siebenmann wrote: > > > (Let me know if you want more detail somewhere here and I can rerun > > > my gdb tracing and/or add printfs appropriately.) > > > > > > Fortunately there is a simple reproduction program mentioned in the > > > Debian bug, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642151 > > > that comes from the Ubuntu compiz bug report. For convenience, I've > > > put it up as its own (shorter) URL: > > > https://www.cs.toronto.edu/~cks/tmp/fvwm/link.py > > > and my fvwmrc: > > > https://www.cs.toronto.edu/~cks/tmp/fvwm/fvwmrc-2.5 > > > > > > If you have the Python GTK bindings (so that link.py runs at all), it > > > puts up a label box with an underlined link. > > > > No idea, but the window with the "link" appears. > > > > > If you click on the link, it's supposed to print something like: > > > > > > link <gtk.Label object at 0x7f64ef58dd70 (GtkLabel at 0x55f69d5c4d40)> > > > http://gtk.org > > > In a configuration with a Mouse 1 binding that includes the Window > > > context (so W or A), the link can't be activated by clicking mouse-1 > > > and link.py prints nothing. You can however get it to print something > > > by clicking on the link and then hitting Return to activate the link > > > through the keyboard. > > > > Okay, this is reproduceable. I know nothing about python or Gtk+, > > so this may be easy, but here, when you click on the window, xev > > prints no ButtonPress or ButtonRelease events at all neither with > > nor without the binding. Is there a way so that the program > > prints all events it sees? > > > > The "A" context bindings actually do cause grabbing the button > > with any modifiers globally (in order to cut down the total number > > of grabs, I think). It's just a global mask of buttons to grab > > globally, and most applications don't care about it. There may be > > some change in the sequence of events the application gets, or > > maybe the timestamps, but its hard to say without actually seeing > > the events. > > There's another strange symptom that seems to point to a button > handling problem in the library, as it occurs even without such a > "trigger" binding. Without a "mouse 3 a ..." binding: > > * Move the pointer over "link". The test gets highlighted in > white. > * Push button 3. The text gets a dark grey background, and a > popup menu opens. > * Hit the "Escape" key to close the popup. The text background > is light grey now. > * Do not move the pointer now; otherwise the problem goes away. > * Clicking with button 3 again does nothing. Pressing the > "Return" key still works. > > It seems the library gets confused about the window's state.
Note: This bug is present even in the complete absence of a window manager, when the program runs on a plain, unmanaged X screen. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
