Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support OOPIF #2548

Closed
aslushnikov opened this issue May 15, 2018 · 15 comments
Closed

Support OOPIF #2548

aslushnikov opened this issue May 15, 2018 · 15 comments
Labels

Comments

@aslushnikov
Copy link
Contributor

@aslushnikov aslushnikov commented May 15, 2018

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: #1140 (comment)

@achingbrain
Copy link

@achingbrain achingbrain commented May 15, 2018

It doesn't even need any JavaScript on the page, plain HTML also fails in the same way:

<!DOCTYPE html>
<html>
  <head>
    <title>Where is my iframe?</title>
  </head>
  <body>
    <h1>Hello world</h1>
    <iframe name="bob" src="https://google.com"></iframe>
  </body>
</html>

@aslushnikov
Copy link
Contributor Author

@aslushnikov aslushnikov commented May 18, 2018

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                                                                                                                                                                                                                                                                                   
}) ;

@tomholub
Copy link

@tomholub tomholub commented May 18, 2018

Unfortunately --disable-features=site-per-process does not help for extension frames on standard domains. Still missing. Tested with bundle from #2506

@aslushnikov
Copy link
Contributor Author

@aslushnikov aslushnikov commented May 31, 2018

@tomholub indeed, thanks for pointing out. It turned out extension isolation is hard-coded in chrome/browser/extensions/chrome_content_browser_client_extensions_part.cc.

aslushnikov added a commit to aslushnikov/puppeteer that referenced this issue Jun 1, 2018
This patch disables OOPIF by default.

**NOTE**: this is a temporary bandaid for the time we're crafting
the full-fledged support for site isolation over DevTools protocol.

References puppeteer#2548.
aslushnikov added a commit that referenced this issue Jun 1, 2018
This patch disables OOPIF by default.

**NOTE**: this is a temporary bandaid for the time we're crafting
the full-fledged support for site isolation over DevTools protocol.

References #2548.
@aslushnikov
Copy link
Contributor Author

@aslushnikov aslushnikov commented Jul 4, 2018

For the record: puppeteer v1.5.0 disables out-of-process iframes by default (see #2661). This, however, doesn't apply to extension iframes - these still operate out-of-process.

@Swordyjohn
Copy link

@Swordyjohn Swordyjohn commented Aug 16, 2018

Is there a time frame for OOPIF support?

@aslushnikov
Copy link
Contributor Author

@aslushnikov aslushnikov commented Aug 17, 2018

@Swordyjohn no good eta; is this pressing you in any way?

@Swordyjohn
Copy link

@Swordyjohn Swordyjohn commented Aug 17, 2018

@aslushnikov we are attempting to use Puppeteer for scraping a site with strong content security in a business setting (I'm an RPA in background screening) and we have had more success than other methods but we cannot access reCaptcha src info when served in order to export it to a click farm due to the OOPIF so we will probably try different automation frameworks.

@tomholub
Copy link

@tomholub tomholub commented Aug 19, 2018

@Banou26
Copy link

@Banou26 Banou26 commented Jan 16, 2019

Any updates on this ? I really need OOPIF.
Any way i can help on this ?

@dennisfrostlander
Copy link

@dennisfrostlander dennisfrostlander commented Feb 26, 2019

Not sure if it solves a problem with extensions, but here is what seems to be the proper way to work with out-of-process iframes.
https://bugs.chromium.org/p/chromium/issues/detail?id=924937#c13

@Banou26 Banou26 mentioned this issue Mar 1, 2019
16 tasks
LarenDorr added a commit to LarenDorr/puppeteer that referenced this issue Mar 19, 2019
This patch disables OOPIF by default.

**NOTE**: this is a temporary bandaid for the time we're crafting
the full-fledged support for site isolation over DevTools protocol.

References puppeteer#2548.
aslushnikov added a commit to aslushnikov/puppeteer that referenced this issue May 29, 2019
@benbuzbee
Copy link

@benbuzbee benbuzbee commented Nov 7, 2019

@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.

@benkauffman
Copy link

@benkauffman benkauffman commented Nov 27, 2019

+1

@Banou26
Copy link

@Banou26 Banou26 commented Nov 27, 2019

Don't do that guys... It's useless, just use the reactions instead...
All it does is notify people watching this thread for nothing, no value added

sadym-chromium added a commit that referenced this issue Sep 21, 2020
…#6432)

Debug message clarifying the problem like `Issue 1060080: Event Network.loadingFinished is not sent when a frame is loaded from another domain`: https://bugs.chromium.org/p/chromium/issues/detail?id=1060080).
It can help users to identify problem with OOPIF easier without digging into the CDP protocol implementation like in the bug `1060080` mentioned above.

To reproduce:
1. Run `DEBUG="puppeteer:frame" NODE_PATH=../ node examples/oopif.js`.
2. Verify the output contains the debug message:
`
puppeteer:frame The frame '...' moved to another session. Out-of-proccess
iframes (OOPIF) are not supported by Puppeteer yet.
#2548
`
jschfflr added a commit that referenced this issue Oct 28, 2021
This pull request to adds better support for OOP iframes (see #2548)

The current problem with OOP iframes is that they are moved to a different target. Because of this, the previous versions of Puppeteer pretty much ignored them.
This change extends the FrameManager to already take OOP iframes into account and hides the fact that those frames are actually in different targets.
Further work needs to be done to also make the NetworkManager aware of these and to make sure that settings like emulations etc. are also properly passed down to the new targets.
@clouedoc
Copy link

@clouedoc clouedoc commented Nov 30, 2021

Should this issue be closed by #7556 ?

@OrKoN OrKoN closed this Dec 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants