add interactiveElement to Keyboard peripheral event

[JayPanoz]

This is pretty much required if you do not want to trigger an action while some interactive element is focused within the iframe e.g. navigating using arrows, etc.

It also improves the logic to check interactive elements by covering additional cases.

[JayPanoz]

So an interesting development with keyboard peripherals is that I genuinely don’t know how to handle their intersection with interactive elements in a reliable way e.g. custom peripherals being arbitrary, you may, or may not want to preventDefault in an input for instance.

Let’s imagine one of your shortcut is just key b for bookmarking or ArrowRight for navigating, you do not want this to preventDefault() and trigger the peripheral event if an input is focused, for obvious reasons. But some other shortcuts like IDK, zooming, you want to preventDefault() even if an input is focused.

The complexity being event is not clonable through window.postMessage so you cannot preventDefault() in the host app.

Adding interactiveElement to the data sent can probably help observe how much that happens, but at this point it is already too late, you cannot “unprevent” the event.

Attempts at smart-ish heuristics for contextual prevention helped surface possible corner/edge cases, especially with inputs because well, on some platforms, you achieve some accented letters or special characters with a combination that may be a custom shortcut at the same time, so it is very difficult to handle this properly, in a manner that makes sense to the person who customised peripherals.

This may be considered an OK limitation in EPUB, but on web it is not sustainable, we cannot break input like this. In some circumstances, with other interactive elements, it could also accidentally break accessibility.

So even if I merge this for short-term use cases, there’s more work awaiting.