For those without time to confirm this bug I attached a gif showing exactly the bug happening in a few seconds. Chrome was launched using the disable-web-security flag and then the bug was easily reproduceable. I really hope this helps :)

Deleted: oficial.gif 993 KB

	oficial.gif 993 KB View Download

Able to reproduce the issue on reported chrome version 66.0.3359.139 & latest stable 67.0.3396.62  and on latest chrome 69.0.3452.0 using Windows 10 using ubuntu 14.04 and Mac 10.13.1. 
 
Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.Attaching screencast for reference.

Thanks! 

Deleted: 849708.mp4 2.9 MB

	849708.mp4 2.9 MB View Download

reporter, can you confirm if the newly opened window is in the same process as the jsfiddle tab? You can look at the Chrome Task manager (Shift-Esc) to check this

@phanindra.mandapaka@chromium.org thanks for verifying the bug!

@dcheng@chromium.org I dont know how to check if they are running in the same process but I did what you asked and pressed SHIFT+ESC and the print is attached.

Deleted: jj.jpg 103 KB

	jj.jpg 103 KB View Download

The last column in the task manager is process ID. I see http://www.metrotatuapeconsorcio.com.br/fale-conosco in the list of open tabs, but not the jsfiddle tab: can you confirm if the process IDs for those two tabs are different?

I have the same problem. Someone else has reported the issue on the chrome-discuss mailing list, too, and points out that disabling site isolation fixes the problem: https://groups.google.com/a/chromium.org/d/msg/chromium-discuss/9X7OfRCQ51Q/b9e7LNlgBwAJ

While there's no command line switch to disable site isolation entirely, I've found that the following command line options seem to fix the problem:

--disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating

This is the command line option discussed on the documentation page for site isolation: https://www.chromium.org/Home/chromium-security/site-isolation

Hope that helps!

@dcheng@chromium.org I did exactly what you said and I made another printscreen getting the most things on the screen that I could. Please check attached file.

@ninten...@gmail.com I tried what you said and it didnt work. I tried launching my Chrome with the command below and the error still happens.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --disable-popup-blocking --disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating --user-data-dir "http://jsfiddle.net/kfpuze7n/"

Deleted: aaa.jpg 336 KB

	aaa.jpg 336 KB View Download

Interesting; I can confirm that my workaround does not work for your use case. I had not realized that you are opening a new tab. I used my workaround to successfully access iframes embedded within a webpage, but had not tested accessing a separate tab / top-level window context. Opting out of the site isolation trail also did not fix the issue.

Just to document what I tried, I ran the following command, and also navigated to chrome://flags to opt out of the site isolation trail:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security --disable-popup-blocking --disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating --user-data-dir=/tmp/foobar https://jsfiddle.net/kfpuze7n/

(I am running a Mac, so this bug is OS independent.)

I have also taken a screenshot of the Chrome Task Manager, which shows that the tabs are running in separate processes. Hope that helps!

Deleted: Screen Shot 2018-06-08 at 10.23.28 AM-fs8.png 37.7 KB

	Screen Shot 2018-06-08 at 10.23.28 AM-fs8.png 37.7 KB View Download

@ninten...@gmail.com thanks for you explanation, indeed in my case I am opening a new tab/window and not accessing and iframe (which IMHO should be affected the exactly same way when using --disable-web-security).

In your screenshot at your Mac the processes as running separetly, just like mine (Windows). 

I really use A LOT this disable-web-security switch for debugging and it's being really hard to workaround this cause firefox has a very weird way to allow that so I prefer stick with chrome and wait for a fix.

The flags mentioned in comment 8 don't disable Site Isolation, just one part of it called Cross-Origin-Read-Blocking (CORB).  However, you should be able to disable Site Isolation when running with --disable-web-security to get the old behavior to work again.  For example:

--disable-features=IsolateOrigins,site-per-process --disable-web-security

Site Isolation breaks this use case because it puts cross-site subframes in a different process than their parent frame, so the direct script access isn't possible anymore.  We don't intend to change that aspect of Site Isolation, which is a Chrome architecture change meant to improve security between websites in the browser.  However, the workaround of disabling both modes for debugging should be sufficient.  (Marking WontFix since it's working as intended.)

Using the flags below didnt work:

--disable-features=IsolateOrigins,site-per-process --disable-web-security

The same bug happens. BUT I think the "--disable-web-security" by itself should be enough to allow an opener to access the content of the opened window. It makes no sense using demanding users to use "--disable-features=IsolateOrigins,site-per-process" in order to get this bug solved (and it doesnt cause disable-features flag is not working either).

--disable-web-security always worked just fine.

 Issue 851856  has been merged into this issue.

Comment 14: I'm curious why the flag isn't resolving the problem.  It looks like it allows subframes to stay in the same process (and be accessed cross-origin when --disable-web-security is used), but for some reason your test page is still putting the popup in a different process.

Alex and I will take a look to see why that's the case.

creis@chromium.org and alex...@chromium.org I wish I could help more but I dont know the reason why the window is being opened in a new process. Thnks for your help into this issue!

It looks like a redirect is causing the process swap.  The repro page does a window.open to http://www.metrotatuapeconsorcio.com.br/fale-conosco, but that redirects to https://metrotatuapeconsorcio.com.br/fale-conosco (which is HTTPS and omits the www).

As a workaround, you can use the destination URL in the window.open call to keep it in the same process, in which case disabling Site Isolation and using --disable-web-security work.

We'll look into why the process swap is happening on redirect, when Site Isolation is disabled.  We think the new navigation logic (PlzNavigate) might be involved.

As for making --disable-web-security work on its own (e.g., causing it to disable Site Isolation as well), I want to get a better sense for what our plans for that flag are in issue 327804.  If we can limit the scope to the sites being tested, that's far less risky than turning everything off.

@creis@chromium.org AMAZING!!! What you said did the trick! Indeed if the destination domain of the opened window or the iframe makes a redirect it may end up in a different process and thus this bug happens. However if the redirect does not happen this bug also does not happen! Right on the point!

I can confirm @creis solution indeed worked (opening the window already with the final domain avoiding redirects). But I still wish this bug could be solved cause I debug hundreds of domains everyweek and I dont usually pay attention to the redirect.

Yes, we'll look into the redirect issue.  Sorry that it hasn't happened yet-- we just haven't gotten a chance.