For e10s, iframes are in the same process as their embedder document, so the content process directly tells the parent process to add the embedded iframe document as a child of the embedder iframe accessible. For Fission, the iframe document is in a different process. When the embedded iframe content process tells the parent process about the iframe document, it will not have the actor for the parent document accessible, nor will it know the accessible id of the embedding iframe.
Bug 1543282 will expose the iframe accessible id on BrowserBridgeParent. With that, when the parent process is notified that the embedded iframe document has been added (TabParent::RecvPDocAccessibleConstructor with no parent doc or id), it must:
- Find the DocAccessibleParent for the embedder document. This will be done by getting the embedded CanonicalBrowsingContext from the embedded TabParent, getting the embedder WindowGlobalParent from that CanonicalBrowsingContext, getting the embedder TabParent from that WindowGlobalParent and finally getting the embedder DocAccessibleParent from that TabParent. (This requires bug 1525427.) If this doesn't exist, it isn't an embedded document; it is top level and the existing behaviour for top level documents should apply.
- Find the id for the embedder iframe accessible. This will be done by getting the BrowserBridgeParent from the embedded TabParent and getting the iframe id from there as exposed in bug 1543282.
- Add the embedded iframe document as a child of the embedder document (using DocAccessibleParent::AddChildDoc), similar to the existing behaviour for e10s when the aParentDoc and aParentID arguments are provided.