mupdf not responding to key events

[Jiang]

This is probably a minor problem peculiar to this particular program, but perhaps the underlying bug is implicated in other problems, too.

The program in question is an extremely fast pdf reader called mupdf
​http://mupdf.com/
I downloaded the program from the website and compile it. I use it to quickly peek a pdf document.
In version 0.15, I can use the usual keyboard shortcuts to resize the window (e.g. + or -) reload the page (r) etc. However, none of these single key shortcuts work in 0.16.
I don't see any error in the log on the server or client side.

My systems are 64 bit 0.16.1-1 beta, released on Dec. 30 2015, on Ubuntu 14.04, both installed from the beta .deb files from the xpra website (thank you for keeping us trusty people afloat with these beta packages!) I am using rgb raw images with lz4 compression.

As I said, I have only observed the problem with mupdf, but not many other programs use single key shortcuts so this may affect other things as well.

Also, it appears 0.16 branch has much better-behaved audio and the audio-video sync is much better, just as promised! Thank you for these improvement!

[Antoine Martin]

As I said, I have only observed the problem with mupdf, but not many other programs use single key shortcuts so this may affect other things as well.

Thanks for reporting this!

Confirmed.
With 0.15.x server (client version makes no difference):

• client:

  send_key_action(2, <GTKKeyEvent object, contents: \
      {'modifiers': ['mod2', 'shift'], 'group': 0, 'string': '+', \
       'keyname': 'plus', 'pressed': True, 'keyval': 43, 'keycode': 21}>)
  send_key_action(2, <GTKKeyEvent object, contents: \
      {'modifiers': ['mod2', 'shift'], 'group': 0, 'string': '+', \
       'keyname': 'plus', 'pressed': False, 'keyval': 43, 'keycode': 21}>)
  

• server:

  get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
  handle_key(2,True,plus,43,21,('mod2', 'shift')) keyboard_sync=True
  is_modifier(21) not found
  handle keycode pressing 21: key plus
  fake_key(21, True)
  scheduling key repeat timer with delay 500 for plus / 21
  get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
  handle_key(2,False,plus,43,21,('mod2', 'shift')) keyboard_sync=True
  is_modifier(21) not found
  handle keycode unpressing 21: key plus
  fake_key(21, False)
  

---

With 0.16:

• server:

  get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
  filtered_modifiers_set(['mod2', 'shift'])=shift, mod2
  filtered_modifiers_set(('mod2', 'shift'))=shift, mod2
  handle_key(2,True,plus,43,21,('mod2', 'shift')) keyboard_sync=True
  is_modifier(21) not found
  handle keycode pressing 21: key plus
  fake_key(21, True)
  scheduling key repeat timer with delay 500 for plus / 21
  get_keycode(21, plus, ('mod2', 'shift')) native keymap, using unmodified keycode: 21
  filtered_modifiers_set(['mod2', 'shift'])=shift, mod2
  filtered_modifiers_set(('mod2', 'shift'))=shift, mod2
  handle_key(2,False,plus,43,21,('mod2', 'shift')) keyboard_sync=True
  is_modifier(21) not found
  handle keycode unpressing 21: key plus
  fake_key(21, False)
  

Bar some logging differences, the steps look identical.

xev shows identical events:

KeyPress event, serial 37, synthetic NO, window 0xc00001,
    root 0x25d, subw 0x0, time 11193155, (88,90), root:(2083,194),
    state 0x11, keycode 21 (keysym 0x2b, plus), same_screen YES,
    XLookupString gives 1 bytes: (2b) "+"
    XmbLookupString gives 1 bytes: (2b) "+"
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0xc00001,
    root 0x25d, subw 0x0, time 11193227, (88,90), root:(2083,194),
    state 0x11, keycode 21 (keysym 0x2b, plus), same_screen YES,
    XLookupString gives 1 bytes: (2b) "+"
    XFilterEvent returns: False

So I suspect that the problem is not in the keyboard layer but maybe focus related instead.
One way to identify the problem would be to bisect it...

[Antoine Martin]

• r11000: bad
• r10000: bad
• r9000: good
• r9500: good
• r9800: good
• r9900: bad
• r9850: bad
• r9825: good
• r9837: good
• r9843: bad
• r9840: bad
• r9838: good
• r9839: bad

r9839 is the problem, and it is focus related.

[Antoine Martin]

Should be fixed in r11742, will backport.

[Antoine Martin]

Backport to v0.16.x in r11748, there are ​beta builds for trusty with this fix.

If this works for you, please close this ticket. Many thanks for reporting this regression!

[Jiang]

This defect is fixed in the latest beta. Thank you for that!

However, mupdf is still not behaving properly as before or as under forwarded X11 window. I've filed a new ticket #1097.