+nasko@, in your comment #12 from crbug/869062, you mention that multiple frames may share a single RenderWidgetHost. When that occurs, is there any way to distinguish which frame had the input event? Or will this bug require changes to the way events are dispatched?

kenrb@ is the expert on input events with multiple processes. I think we know which frame it is inside the renderer process, but not sure if this information is available in the browser.

As Nasko mentioned, there is a one-to-many relationship between RenderWidgetHosts and RenderFrameHosts. In general we route input events through RenderWidgetHosts, and frame-level dispatching is done in the renderer process.

In the case of keyboard events the browser process could hypothetically infer which frame will receive the event, because it does know which frame is currently focused -- e.g. RenderFrameHostImpl::IsFocused(). I don't know if this information is exposed though the content API (it doesn't look like it). Also it could sometimes be wrong because of race conditions, where for instance a keyboard event is being processed in the browser process and the focused frame is simultaneously changing in the renderer process. If you want to know with certainty which frame received a keyboard event then you would have to plumb that information in an acknowledgement from the renderer.

After a little more consideration, I don't think this is possible to do with any kind of reliability. My first concern was that focus can be moved around with JS, allowing different frames to each get part of the password and then stitch it back together. This seems to limit us to indicating which SiteInstance used the password.

But this can be extended to cross-origin frames, using postMessage, if the main frame is malicious. Since we have no way of determining which frames have knowledge of the key presses, there's no reasonable definition of "which frame" had the password reuse. I think we'll have to settle for aggregating over the whole WebContents, and reporting the main frame URL.

Thanks for investigating this Dan!