Description of Change

In our security recommendations guide, we list validating senderFrame of IPCs. In the case of IPCs sent after the unload event, it's possible for senderFrame to point to a different RenderFrameHost than the sender of the IPC.

The process occurs as followed (gist to repro):

1. WebFrameMain is set to RFH A
2. Cross-origin navigation begins
3. WebFrameMain is swapped to RFH B
4. Window 'unload' listener is emitted in RFH A, now marked as kPendingDeletion
5. RFH A sends an IPC during the unload listener
6. IPC is received with senderFrame pointing to RFH B

WebFrameMain internally indexes a RFH by its FrameTreeNode ID. This is based on the design of WebFrameMain being similar to how <iframe> works.

By introducing a "pinned" WebFrameMain, we can ensure the data is immutable and won't update in the case of cross-origin navigation frame swaps.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation, tutorials, templates and examples are changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes:

• Added "pinned" WebFrameMain variant used by IPC's senderFrame to ensure immutability of the sender.
• Added webFrameMain.fromFrameTreeNodeId(frameTreeNodeId) as a method to get a WebFrameMain instance independent of its process and frame IDs.
• Fixed webFrameMain.fromId(processId, frameId) returning a WebFrameMain which doesn't match the given parameters in cases where a cross-origin navigation occurred.