One idea would be to insert a "background element" into your UI, which stretches across the entire context and then attach an event listener to that, which detects mouse-move events. So when you know your mouse moved and inject that into Rocket and your listener on the background element does not get a mouse-move event, then rocket handled it internally for some other element (same for mouse clicks).

You could actually just take the data from the background element and feed that back into your engine (mouse-moves / clicks / etc.).

I haven't tried this, have just stumbled across Rocket and this particular issue and would be interested in hearing, whether this solves this important issue, so let me know what you come up with.

Yeah, that's what I've ended up doing, and it's what the "space invaders" sample project that comes with libRocket seems to do anyway.

Specifically I've created a GameDocument class that subclasses Rocket::Core::ElementDocument. This wraps the base input, updating, and rendering of the game itself. To use it I created a subclass of Rocket::Core::ElementInstancer called GameDocumentInstancer. The GameDocumentInstancer sets a new GameDocument's width and height attributes to "100%" to make it cover the screen and its z-index attribute to "bottom" to make sure the GameDocument never floats to the top over any standard documents.

I could have also just subclassed Rocket::Core::Element, but then I'd need a separate RML file containing the game element with the width, height, and z-index attributes set correctly.

The only thing I'm left with now is how to make key input "default" to the background game document. If I click on any control besides the game document, key events don't go to the game document until I click it.