Support OOPIF

Out-of-process iframes are here now and have to be supported.

For the following HTML served from localhost, pptr fails to report the frame:

<h1>Hello world</h1>
<script>
  const frame = document.createElement('iframe')
  frame.setAttribute('name', 'bob')
  frame.setAttribute('src', 'https://google.com')
  document.body.appendChild(frame)
</script>

Original example: https://github.com/achingbrain/puppeteer-frames Reported here: https://github.com/GoogleChrome/puppeteer/issues/1140#issuecomment-389054750

[aslushnikov]

While we’re figuring this out, a workaround is to run with --disable-features=site-per-process flag:

const browser = await puppeteer.launch({                                                                                                                                                                                                                                                            
  args: ['--disable-features=site-per-process'],                                                                                                                                                                                                                                                    
  headless: false                                                                                                                                                                                                                                                                                   
}) ;

[benbuzbee]

@aslushnikov could be willing to take a stab at this but how long this issue has been neglected makes me nervous that there may be some hidden dangers.

What would you say are the major concerns?

The change seems something like

• use target attached/detatched/destroyed events with type=iframe as a hint to the frame tree and update the frame manager accordingly https://cs.chromium.org/chromium/src/content/browser/devtools/protocol/target_auto_attacher.cc?type=cs&sq=package:chromium&g=0&l=173

• The frame needs its own CDPSession if created in this way instead of inheriting the parents so that it can use a separate sessionid, seems relatively straight-forward. Seems to be some finagling to do here so each instance ignores messages not meant for it

• Commands that use the devtools Page domain that aren’t already on the Frame class may need to be changed to send to all frame’s sessions This one may be sketch. Some commands will be fine, like captureScreenshot which can exist only being dispatched to the root frame, but others wont. It looks like Page.addScriptToEvaluateOnNewDocument doesn’t filter to OOPIF so Page::exposeFunction() won’t work for them. That said, this limitation seems like something that could be slowly addressed over time in the future and not having it but having most other things seems strictly better.