Window Controls Overlay: alignment with visual viewport and the virtual keyboard API

[BoCupp-Microsoft]

FYI that there is some similarity between laying out content around the virtual keyboard and laying out content around the window controls. I think there is opportunity to better align the concepts.

For example, it sounds like you'll rely on the window resize event, but the Virtual Keyboard API leverages an overlaygeometrychange event targeted at the VirtualKeyboard object. I think it might be better to have the more specific event to avoid over-invalidation of the page.

Note there is also discussion in this issue about whether we should be finding a way to extend the Visual Viewport API instead. Could you share your thoughts on whether there's an opportunity to integrate this proposal into the Visual Viewport API or whether you think it should remain separate and why?

Thanks!

[amandabaker]

We can introduce a unique event for when the overlay is changed, and there's a discussion about it here #274 and here #184. It might make sense to even use the same event name, overlaygeometrychange and just target it at the controlsOverlay instead?

If Visual Viewport is extended to support non-rectangular displays, then it would be great to align with that and define the available area rather than the unavailable area (which is what controlsOverlay.getBoundingRect() describes).

[BoCupp-Microsoft]

I'm in favor of aligning the event name and having the event targeted at your controlsOverlay object. Note that in a TAG review of the virtual keyboard API it was suggested we just call the event geometrychange. We agree with that feedback and it seems like it would be a good name for your event as well.