https://gist.github.com/rlhunt/63a47baaaed3e4f4cb7d17cbb318116c

Getting Information
- seems reasonable
- For 2.i.b, RefLayers tend not to have a ViewID, so you might need to make the "AsyncKeyboardScrollingTarget" some sort of union type where it could be a ViewID or a sub-layer-tree-id

Input Handling
- I would prefer 2.ii instead of 2.i
- For 3.ii I think skipping async scrolling will probably be easier the initial version. the key listeners might also change focus which might be a little tricky to handle
--> Yeah, I don't think there's much to be gained from waiting for a content response if there's a keyboard event listener. If we have to wait for the content anyways, we might as well just have it do the scrolling. (For things like touch gestures, multiple events are coalesced into the same "block" and only the first one can be preventDefaulted, so it's worthwhile to wait for a content response to subsequent events can be processed asynchronously. I don't think that applies to keyboard events.)

I think we'll also need to attach sequence numbers to events, as described in https://public.etherpad-mozilla.org/p/async-keyboard-scrolling

Building a "KeyboardActionMap"
- seems reasonable, i don't know much about the XBL stuff
I assume the KeyboardActionMap can't change over the course of the process' lifetime, and it's thus sufficient to send it to APZ once on startup?

Questions
- For q1, the ancestor scrollable frame should have a ViewID even if it's not layerized. We can check on the APZ side if it's layerized or not (if it's not, it will return true from IsScrollInfoLayer()) and skip APZ scrolling if it's not layerized. The root scrollable should always be layerized and we'll get the biggest wins there anyway
  Being a scroll info layer isn't the only reason a scroll frame might not be layerized. It could simply be inactive, in which case it won't even have a ViewID. This is something we can detect on the Layout side (with FindIDFor()), and just send a null AsyncTarget if it's the case. (Alternatively, we could consider layerizing a subframe whenever keyboard focus enters it, but that's better left as an independent follow-up change.)
- For q2, this should work fine for webrender. We'll need to send the AsyncKeyboardScrollingTarget information over in WebRenderScrollData (see the mIsFirstPaint flag in that class for a model to work off of)
- For q3, yeah I think sending the focus target per-repaint is probably the best place