Readium hijacks keystrokes in interactive content in certain cases

[rkwright]

This issue is a Bug

Related issue(s) and/or pull request(s)

• #506

Expected Behaviour

If interactive content has the focus, it should get the keystrokes, e.g. '1', '2', 'a', etc.

Observed behaviour

Instead, in certain cases, Readium re-directs the keystrokes to its own shortcuts. In the supplied demo file there is a small, simple JavaScript file that handles mouse and touch gestures to control a 3D camera (OrbitControls-Touch.js). It can also handle keystrokes, but in the demo (see below) all key handling is disabled and commented out. If the JS lib (OrbitControls-Touch.js) is not instantiated (its OK to include it) then the demo works fine and the interactive content gets the keystrokes. But if the OrbitControls are instantiated, then Readium gets the keystrokes. There is a keyhandler in the demo's own JS, but it never gets called if the OrbitControls are instantiated. Without instantiating the OrbitControls, all works as expected. On Stackoverflow, one user reported a similar behaviour except the container was JSFiddle, not Readium. But one wonders if it is somehow related - iFrame scoping or something?

Steps to reproduce

1. First, load the file. Go to the demo in Chapter 18. Click on the content to give it the focus
2. Press the '2' key. This should change the type of Quadric from a Cube to a Cylinder
3. Instead, Readium grabs the keystroke and advances to the next page ('2' being the shortcut key for "next page")

Test file(s)

Test file is here

Product

• Readium Chrome extension
  • latest official version available from the Chrome Web Store
  • 2.24-alpha version of the Chrome browser
• Readium cloud reader app
  • Chrome and Safari
• Native application (Readium SDK C++)
  • SDKLauncher-OSX, 0.24-alpha *OSX 10.10

Additional information

None

[rkwright]

I poked at this a little more. If I go to the page with my WebGL demo in it and open the console and type monitorEvents(window) then click the mouse over the WebGL and press the ‘1’ key, I see the keydown event in the console, with this info:

So it looks like the right arrow bar still has the focus – not my WebGL code. Does that sound like the right interpretation? If so, I need to figure WHY my demo doesn’t get the focus or events. The WebGL code DOES get mouse events, but not keyboard events.

[danielweck]

From the top of my head, Readium cloud reader / Chrome app only "redirects" (forces) keyboard focus into a specific desired DOM location in the following cases: TOC hide/show, TOC heading link activation, and popup modal dialogs. So, I think that mouse-clicking on the WebGL area does not actually set keyboard focus. In fact, last time I checked this was a common problem / discrepancy between different web browser implementations: mouse / touch click on UI controls (e.g. buttons, radios, pull down lists) would not necessarily activate keyboard focus and the associated visual highlight "ring", resulting in UX inconsistencies. Side note: CSS user-select: none affects this behaviour too.