Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1067 Keypresses are lost after changing workspaces

future release
open-accepted
Mathias Gumz
None
5
2015-01-21
2012-10-02
Anonymous
No

After changing Fluxbox workspaces (using the keyboard), the first key pressed is lost.
For example: In workspace 3, a terminal window is open. Then switch to the next workspace and then back (Ctrl+Alt+Left per default). Type "abc" - usually only "c" appears in the terminal window.

See Debian bug #612893, especially message 87: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612893#87
He describes it pretty well - if you manage to release the Ctrl and Alt keys before you've arrived on the new workspace, they're not released (race condition).

I'm using Fluxbox 1.3.2 on Fedora (fluxbox-1.3.2-4.fc17.x86_64) and I consider this to be a serious bug. Too many times (using vi), one of the key strokes switching to insert mode has been lost and suddenly D clears the current line.

Discussion

  • joeytwiddle
    joeytwiddle
    2013-06-23

    Some tiny clues that may or may not help to track this down:

    Clue #1

    I notice if the window on the target desktop that should be focused is GVim, then the cursor appears as an unfilled square, not the usual filled square. The first (lost) keystroke converts the cursor back to a filled square. This seems to indicate that whilst Fluxbox has "focused" the window, X keyboard focus is not placed on the window until that first key is pressed.

    This unfilled square is even the case when Fluxbox focuses and raises the window on arrival at the target desktop. (I have focusModel: StrictMouseFocus and autoRaise: true.)

    Clue #2

    If I use bbkeys to switch desktop, keyboard focus appears to work just fine, working around this bug. (Although it's not a great workaround - bbkeys has his own issues: if I press workspace switching keys too fast, the second action will fire as if it was started from the initial workspace, effectively un-doing the first action.)

    Hope this may help!

     
  • joeytwiddle
    joeytwiddle
    2013-06-25

    My plan to fix this

    1. Trace (almost) all the function calls that are made while Fluxbox is running.

    2. Reproduce the bug and press the lost keystroke. This connects our keyboard with the window. (By "connection" I mean that GVim's cursor turns solid and future keystrokes will reach the window).

    3. Now look in the trace to see what function call it was that successfully connected our keyboard with the window.

    4. Add this function call to perhaps BScreen::changeWorkspaceID or FocusControl::revertFocus so that the connection happens automatically in future as soon as we change workspace, without requiring a keystroke or Ctrl/Alt release.

    Unfortunately my attempt at this approach failed because there were too many calls to trace all of them, and when I tried to filter the list down a bit, gdb crashed. Perhaps someone with a better knowledge of C tracing tools can try this.

    Consideration

    This above approach may fail. Fluxbox may already be calling the thing that is supposed to reconnect the keyboard with the window, but it is refusing to do what we need for some reason (perhaps it does not act if it believes Desktop switching is still in progress).

    Clue #3

    The top post correctly says that this bug occurs if we release Ctrl/Alt keys too quickly, before arriving at the new desktop. In fact it is the release of a Ctrl or Alt key that usually triggers the keyboard to be connected to the window. This can be demonstrated: Switch desktop, then without releasing Ctrl-Alt press Backspace. The first time you press the Backspace key the stroke will be lost (but it will trigger connection of the keyboard to the window), the second time you press Backspace, the key will reach the window (producing a flash in vim, or ^E character in xterm). This can also be seen through GVim's hollow/solid cursor changing. Through experiment I note that releasing either Alt or Ctrl alone can trigger the connection (if the other one was released too early); both are not required.

    So ... it is a key release which usually connects keyboard focus to the window.

    Compiling old versions

    I thought I should start a git bisect. So far I have gone back to September 2008 and the bug is still present!

    Unfortunately going back to 2007, I get a compile error I am not sure how to resolve:

    Menu.cc: In member function virtual void FbTk::Menu::keyPressEvent(XKeyEvent&):
    Menu.cc:1071:13: error: find is not a member of std
    

    Although the std::find line is no different from the latest version.

    And Jan 2008:

    FocusableList.hh:111:5: error: auto_ptr in namespace std does not name a type
    

    I think I will stop here for today. :)

     
  • edman007
    edman007
    2013-07-18

    In case anyone here wants to try working on it, I just got a very good test case and used it to git bisect the bug down to the offending commit.

    04a1d2a83b96eb6d1b1958e4f3e25ffdf295aa4d is the bad commit, so that should give you an idea of where to start

    The best test case I got is open 20 xterm windows, and bind workspace switching to f1/f2, run as a a separate user and you can startx and test it without having to login/out and stuff.

    If anyone can help with it, I'll be on IRC all weekend on freenode in #fluxbox, and I'll try fixing it if someone can't fix it first.

     
  • edman007
    edman007
    2013-07-19

    This seems to fix it for me, I think it needs testing, but I see no problems so far. The problem is ungrabbing the keyboard during a KeyPress event destroys the KeyRelease event (or at least we never get it), the later re-grabbing of the keyboard thus gives the keyboard to fluxbox, but the KeyRelease never arrives to ungrab the keyboard. The keyboard needs to stay in a grabbed state to catch everything fluxbox needs (I think).

    I may have broken something, but so far things seem fine for me.

     
  • Mathias Gumz
    Mathias Gumz
    2013-08-02

    we will see what other bugs pop up: i applied this one. thanx for your effort in tracking down the problem.

     
  • Mathias Gumz
    Mathias Gumz
    2013-08-02

    • status: open --> closed-accepted
    • assigned_to: Mathias Gumz
    • Group: --> v1.3.6
     
  • joeytwiddle
    joeytwiddle
    2013-09-01

    Thanks so much guys for this fix. I haven't lost a keystroke since I started using it! Also I haven't noticed any bugs yet. This has greatly enhanced my user experience. Queueing up keystrokes makes me more productive!

     
  • Mathias Gumz
    Mathias Gumz
    2015-01-21

    • status: closed-accepted --> open-accepted
    • Group: v1.3.6 --> future release
     
  • Mathias Gumz
    Mathias Gumz
    2015-01-21

    I reverted the commited change due to regressions in other areas ("autorepeat keys do not work anymore", bug #1115. I consider non-working keys more important than "sometimes lost ones" but I'll do not think this bug here is unimportant.

    The problem might be related to the way autorepeated keys are delivered, or how fluxbox detects and handles things in that area.

    "He describes it pretty well - if you manage to release the Ctrl and Alt keys before you've arrived on the new workspace, they're not released" ... yeah.