[openbox] Openbox context menu not working

[Piscium]

On 28 March 2016 at 15:18, Johan Vromans <jvromans at squirrel.nl> wrote:
> On Sun, 27 Mar 2016 22:45:40 +0100 Piscium <groknok at gmail.com> wrote:
>
>>   On 2016-03-27 20:39 +0100, Piscium wrote:
>>   If you use programs
>>   that link to GNOME libraries, it's likely that some GNOME daemons get
>>   started behind your back.  That is just the way of the GNOME :-(
>
> Exactly. And one of these programs sometimes (cron? yum?)
> sets/resets/overrides something.
>
> Similarly: Sometimes I find that my Xdefaults (yes, I'm old
> fashioned) have been reset so I need to load them again.
>
>> but wouldn't be surprised if it's yet another gnome program stealing
>> events.
>
> This what I expects that happens.
>
>> In any case, as I said before the issue manifests after an apparently
>> random time after login, so there could be an hidden obscure bug
>> somewhere.
>
> I'm afraid it's not a bug, but defined though (for us) unwanted behaviour.
>
> The problem remains to find out what tool is resetting or stealing things.
>
> Right now I have a root window that doesn't any longer respond to mouse
> clicks. There must be a way to find out who is stealing the events...

Well, the reason I believe it is a bug is because I cannot find a
correlation between the issue manifesting and something else, such as
an action of mine.

Dana suggested using "xwininfo" however I got exactly the same result
when the issue is manifesting or not, so no information was gained. I
then started looking at other debugging commands, and in my case I get
different results with the xev command depending on if the issue is
manifesting or not.

I am still exploring what is the best set of arguments to xev (to
filter out some events of no usefulness), but this is my best
suggestion in case you want to try it with the issue manifesting and
not and compare (please remove the quotes that delimit the command):
"xev -root -event expose -event visibility -event structure -event
substructure -event focus -event property -event owner_grab_button
-event randr -event button"

The bug could be in X, who knows. For example, with the issue _not_
manifesting I get this when I right click on the desktop:

$ xev -root -event expose -event visibility -event structure -event
substructure -event focus -event property -event owner_grab_button
-event randr -event button

CreateNotify event, serial 18, synthetic NO, window 0x27f,
    parent 0x27f, window 0x81314b, (0,0), width 1, height 1
border_width 0, override NO

ConfigureNotify event, serial 18, synthetic NO, window 0x27f,
    event 0x27f, window 0x81314b, (0,0), width 1, height 1,
    border_width 1, above 0x2a2326e, override NO

ConfigureNotify event, serial 18, synthetic NO, window 0x27f,
    event 0x27f, window 0x81314b, (0,0), width 1, height 1,
    border_width 1, above 0x80025b, override NO

PropertyNotify event, serial 18, synthetic NO, window 0x27f,
    atom 0x1a0 (_NET_CLIENT_LIST_STACKING), time 56169701, state
PropertyNewValue

ConfigureNotify event, serial 19, synthetic NO, window 0x27f,
    event 0x27f, window 0x81314b, (0,0), width 118, height 269,
    border_width 1, above 0x80025b, override NO

ConfigureNotify event, serial 19, synthetic NO, window 0x27f,
    event 0x27f, window 0x81314b, (127,464), width 118, height 269,
    border_width 1, above 0x80025b, override NO

MapNotify event, serial 19, synthetic NO, window 0x27f,
    event 0x27f, window 0x81314b, override NO

UnmapNotify event, serial 19, synthetic NO, window 0x27f,
    event 0x27f, window 0x81314b, from_configure NO

Expose event, serial 19, synthetic NO, window 0x27f,
    (127,464), width 116, height 271, count 0

DestroyNotify event, serial 19, synthetic NO, window 0x27f,
    event 0x27f, window 0x81314b

PropertyNotify event, serial 19, synthetic NO, window 0x27f,
    atom 0x1a0 (_NET_CLIENT_LIST_STACKING), time 56173182, state
PropertyNewValue
^C