Bizarre key-binding of "Ctrl+a" after upgrade

Syntheticus · 2020-10-08 17:21:55

I upgraded my Bunsenlabs stable to Debian testing (reasons not to mention here), everything went well expect one strange key-binding change occurred: Since the upgrade "Ctrl+a" causes the previous window to come to foreground. I've checked my settings in xbindkey and menu and none of them are set to change anything on "Ctrl+a".

Don't know if this helps but this is my xev output of the "Ctrl+a" combination:

KeyPress event, serial 48, synthetic NO, window 0x7c00001,
    root 0x85d, subw 0x0, time 50940106, (4601,-496), root:(4603,1412),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 48, synthetic NO, window 0x7c00001,
    mode NotifyGrab, detail NotifyAncestor

FocusOut event, serial 48, synthetic NO, window 0x7c00001,
    mode NotifyWhileGrabbed, detail NotifyNonlinear

PropertyNotify event, serial 48, synthetic NO, window 0x7c00001,
    atom 0x1e5 (_NET_WM_ICON_GEOMETRY), time 50941133, state PropertyNewValue

Any hint or help where to look much appreciated!

Last edited by Syntheticus (2020-10-08 19:03:05)

damo · 2020-10-08 18:12:07

The window keybindings for BL are in bl-rc.xml. It sounds like there may be a keybind clash with

....
<action name="PreviousWindow">
....

Syntheticus · 2020-10-08 18:57:10

Thanks, @damo for the hint, the

<action name="PreviousWindow">

is set to the default

<keybind key="A-S-Tab">

if I go through the Openbox & Xbindkeys keybinds there's nothing set to "C-a" and all the other keybinds do work like before the upgrade.

damo · 2020-10-08 19:06:34

C-a presumably is "Select all" for the window the mouse is over.

It seems that the window is being raised when it gets the focus with the select action.

Are you using a new bl-rc.xml after the upgrade? What if you revert to the backup, which BL should have created?

Syntheticus · 2020-10-08 19:44:53

C-a presumably is "Select all" for the window the mouse is over.

indeed and used for instance to cut or mark a url in the browser, therefore this behaviour is slightly annoying.

There was no backup created during the upgrade but I've tried the one from the snapshot before the upgrade and still the same hmm

damo · 2020-10-08 20:58:54

I've just noticed that your xev output doesn't show the "a" keypress. This is the output I get:

KeyPress event, serial 48, synthetic NO, window 0x4c00001,
    root 0x166, subw 0x0, time 9980682, (70,517), root:(804,557),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 48, synthetic NO, window 0x4c00001,
    root 0x166, subw 0x0, time 9981551, (70,517), root:(804,557),
    state 0x14, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (01) ""
    XmbLookupString gives 1 bytes: (01) ""
    XFilterEvent returns: False

Syntheticus · 2020-10-08 21:49:07

Creating a test user and log into the test account results in the same behaviour. Login into fluxbox changes the "effect", no bizarre window focus on "Ctrl+a" anymore, so it seems to be an openbox configuration problem, however bit stumped atm where to find the fly in the ointment...

Syntheticus · 2020-10-08 21:50:37

damo wrote:

I've just noticed that your xev output doesn't show the "a" keypress. This is the output I get:

KeyPress event, serial 48, synthetic NO, window 0x4c00001,
    root 0x166, subw 0x0, time 9980682, (70,517), root:(804,557),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 48, synthetic NO, window 0x4c00001,
    root 0x166, subw 0x0, time 9981551, (70,517), root:(804,557),
    state 0x14, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (01) ""
    XmbLookupString gives 1 bytes: (01) ""
    XFilterEvent returns: False

For any other keycombo I get a similar pattern

Syntheticus · 2020-10-13 16:52:24

I think I found the needle in the Haystack by accident trying things in this threat (https://bugzilla.icculus.org/show_bug.cgi?id=6553): playing around I found out the previous window that comes to the foreground on "Ctrl+a" is always the same first window opened when openbox is started. When closing that first window, e.g. a terminal, everything is normal, "Ctrl+a" selects all smile

#1 2020-10-08 17:21:55

Bizarre key-binding of "Ctrl+a" after upgrade

#2 2020-10-08 18:12:07

Re: Bizarre key-binding of "Ctrl+a" after upgrade

#3 2020-10-08 18:57:10

Re: Bizarre key-binding of "Ctrl+a" after upgrade

#4 2020-10-08 19:06:34

Re: Bizarre key-binding of "Ctrl+a" after upgrade

#5 2020-10-08 19:44:53

Re: Bizarre key-binding of "Ctrl+a" after upgrade

#6 2020-10-08 20:58:54

Re: Bizarre key-binding of "Ctrl+a" after upgrade

#7 2020-10-08 21:49:07

Re: Bizarre key-binding of "Ctrl+a" after upgrade

#8 2020-10-08 21:50:37

Re: Bizarre key-binding of "Ctrl+a" after upgrade

#9 2020-10-13 16:52:24

Re: Bizarre key-binding of "Ctrl+a" after upgrade

Board footer