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
Comments
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> |
While we're figuring this out, a workaround is to run with const browser = await puppeteer.launch({
args: ['--disable-features=site-per-process'],
headless: false
}) ; |
Unfortunately |
@tomholub indeed, thanks for pointing out. It turned out extension isolation is hard-coded in |
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.
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.
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. |
Is there a time frame for OOPIF support? |
@Swordyjohn no good eta; is this pressing you in any way? |
@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. |
It's pressing us too - cannot test extension frames inside non extension
tabs.
…On Fri, 17 Aug 2018, 20:38 Swordyjohn, ***@***.***> wrote:
@aslushnikov <https://github.com/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 may need to
explore other methods.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2548 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGA8kVHsMCuA9DAiofNCudL1Ta-WLT-wks5uRsdbgaJpZM4T-_qM>
.
|
Any updates on this ? I really need OOPIF. |
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. |
Reference puppeteer#2548
@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
|
+1 |
Don't do that guys... It's useless, just use the reactions instead... |
…#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 `
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.
Should this issue be closed by #7556 ? |
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:Original example: https://github.com/achingbrain/puppeteer-frames
Reported here: #1140 (comment)
The text was updated successfully, but these errors were encountered: