It is unclear how isInputPending should work if focus is moved to another iframe when there is a pending key event

[smaug----]

Some spec should define the order of focus and key events and how it all works with isInputPending

[npm1]

@acomminos this is blocking Mozilla's implementation, could you take a look?

[acomminos]

The spec outlines the solution space for this case briefly:

The case of a child cross-origin subframe is even trickier to deal with, as the frame that gets an event may change based on what script is currently doing. In some cases a malicious cross origin frame could attempt to bring focus to itself in order to look for input events that a user could have intended to be sent to the parent frame. For example, a malicious origin could attempt to get a user to click on a child iframe by moving it around the screen. Some user agents mitigate this by discarding input events on recently moved frames. User agents should pay special attention to this case, and add appropriate countermeasures to their implementations of this api based on their architecture.

Normative steps on determining the origin responsible for a given event are likely outside of the scope of the API. Given these cases orient around cross-origin iframes, perhaps HTML may be a good place for this?