I don't know why this is happening already now. But in my opinion, LibVLC should not catch key presses at all. It is really up to applications using LibVLC to do that.
Replying to [comment:1 courmisch]:
Yes, for a subset of its usages it is interesting to not have libvlc catching hotkeys. It can be suitable for something like "kiosk" modes if someone use it this way.
I have to say it is a good thing (and simpler :) in web plugins usages, it makes common VLC hotkey usable in fullscreen view. Maybe a compromise can be found to have an option like "--no-hotkey" to allow both usages.
The point's not about kiosk. The point is that libvlc applications most often include their own UI. Said UI is not unlikely to handle key presses differently, when the video has focus. VLC hotkeys should not go in the way of third party UIs.
For kiosk mode, we already have had the vout-event parameter.
Anyway, I have no idea why this bug occurs with the Xlib plugins (and I am not looking at it).
I don't remember what the situation was 3 years ago. But now the problem is painfully obvious: key presses are not dispatched properly. In fact, there is no (and never was) a dispatch mechanism for key presses... Currently, all events are sent to the "hotkey" plugin. And that plugin only operates upon the VLC playlist, the VLC playlist input and/or the first video output of the VLC playlist input.
With the Mozilla plugin, the VLC playlist is not used, rather libvlc_media_player API. So key events have no effects. In fact, this problem can even affect VLC itself: key presses also do not work with VLM, and nod properly with audio visualization or multiple video outputs.
Fixing this issue would require a major rework of the keyboard handling. Patch welcome.