Console keeps showing an error Uncaught DOMException: Blocked a frame with origin from accessing a cross-origin frame.

[s-syam]

What is your Test Scenario?

The user is trying to log in

What is the current behavior?

When a user tries to login from an iframe popup which has a redirect after successfully logging,user is stuck on the login popup and the user is not logged in

What is the Expected behavior?

User is allowed to be logged in

What is your web application and your TestCafe test code?

fixture `MyFixture`
   .page('https://www.hoefenhaag.nl/');
test('Test1', async t => {
   await t
      .maximizeWindow()
      .click('button.module-cookies-close')
      .click('a.button-full')
      .click('div.js-navigation-login-heart-bg')
      .switchToIframe('#login-iframe')
      .typeText('input[name*="account_email"]', 'test08@mailinator.com')
      .typeText('input[name*="account_password"]', 'Qwerty123$')
      .click('#button-submit')
      .switchToMainWindow();

});

Steps to Reproduce:

Steps described above, Error : Uncaught DOMException: Blocked a frame with origin "xxxxxxx" from accessing a cross-origin frame.

Your Environment details:

• testcafe version: 1.9.1 also 1.9.4
• node.js version: 12.18.2

[Farfurix]

@theTainted

Hello,

I tried to log in without using TestCafe and got the same result: I stuck on the login iframe. I used your test account and another one (I registered a new account). Could you please describe steps to log in without using TestCafe?

[s-syam]

without testcafe please use the below flow Access https://www.hoefenhaag.nl/ Click on Close icon on the slide-out that's present in the right side Click on the person icon enter test08@mailinator.com and the password as Qwerty123$ and click on login

[Farfurix]

@theTainted

Thank you for the clarification. I reproduced the issue using testcafe-hammerhead. Our team will research it and check for a suitable solution.

For the team. It is not possible to log in without TestCafe using the Chrome Incognito Window.

set NODE_OPTIONS="--insecure-http-parser"
gulp http-playground

[s-syam]

Hello, do we have any time lines for this issue's fix? Thanks

[Farfurix]

@theTainted

Hello,

I cannot give you time estimates on when this issue will be fixed. We will update this thread once we have any results.

[s-syam]

Thanks for responding. This for me is a blocker, so was curious if there is any kind of workaround for the issue?

[Farfurix]

@theTainted

There is no workaround at the moment.

[s-syam]

Hi, Any updates on this, its a blocker for me :(

[Farfurix]

@theTainted

Hello,

We have no updates yet.

[s-syam]

Hi, Is there any solution or workaround for this?

[github-actions[bot]]

There are no workarounds. Once we get any updates, we will post them in this thread.

[Testcafefan]

Any update on this issue? Or a work around.. we cannot login with testcafe due to this error. any help is much appreciated

[github-actions[bot]]

No updates yet. Once we get any results, we will post them in this thread.

[LavrovArtem]

A simple example for reproducing:

const http = require('http');

http
    .createServer((req, res) => {
        if (req.url === '/') {
            res.writeHead(200, { 'content-type': 'text/html' });
            res.end(`<iframe src="http://localhost:2022/"></iframe>`);
        } else if (req.url === '/ok') {
            res.writeHead(200, { 'content-type': 'text/html' });
            res.end(`
                <script>
                    top.document.body.append('Ok!');
                    top.document.querySelector('iframe').remove();
                </script>
            `);
        } else
            res.destroy();
    })
    .listen(2021, () => console.log('http://localhost:2021/'));

http
    .createServer((req, res) => {
        if (req.url === '/') {
            res.writeHead(200, { 'content-type': 'text/html' });
            res.end(`<form action="http://localhost:2023/login" method="post"><input type="submit"></form>`);
        } else
            res.destroy();
    })
    .listen(2022);

http
    .createServer((req, res) => {
        if (req.url === '/login') {
            res.writeHead(302, { location: 'http://localhost:2021/ok' });
            res.end();
        } else
            res.destroy();
    })
    .listen(2023);

[dbfr3qs]

We got around this in our team by disabling web security in chrome when running testcafe, eg.

testcafe -e "chrome:headless --disable-web-security" ...

See https://stackoverflow.com/questions/3102819/disable-same-origin-policy-in-chrome/3177718#3177718

[miherlosev]

Hi @s-syam,

TestCafe runs tests using the URL-rewritten proxy. This approach is good. However, there is a way to improve the stability and speed of test execution - the native browser automation API. We have a test execution mode uses native browser automation - we call it the Proxyless mode. In Proxyless mode, a few issues are already fixed. By the way, this issue was also fixed in Proxyless mode. This option is available in all interfaces:

// Command-line
testcafe chrome tests --experimental-proxyless

// Programmatic
const testcafe = await createTestCafe({ experimentalProxyless: true });

// Configuration file
{
   "experimentalProxyless": "true"
}   

Setup the testcafe@2.1.1-alpha.3 version and try running your tests in Proxyless mode. I look forward to your results. Note that at present it is an experimental mode. Also, the Proxyless mode is implemented only in Google Chrome. It will not work correctly if you run tests in a non-Chrome browser or in a combination of other browsers.

[kerrijackson]

FYI --experimental-proxyless did not solve the problem for us. --disable-web-security did solve the problem.

[miherlosev]

Hi @kerrijackson,

--disable-web-security did solve the problem.

I am happy to hear that. Note that experimental-proxyless mode has become a regular option, and was renamed to native-automation. You can try to use it one more time.

[miherlosev]

Hi @s-syam,

This issue is not reproduced with combination of testcafe@3.0.1 and the Google Chrome browser. Feel free to reopen this issue if you encounter it in other browsers.

[patrickathompson]

The offending code in our use case was this visible check on a modal div embedded in an iframe:

await t.expect(zipCodeModalDiv.visible).ok()

Once replaced with another suitable check on another div not using .visible and the issue was resolved.

It was almost consistently reproducible on 'browserstack:Samsung Galaxy S22@12.0', which uses Samsung Internet, but we also observed the error intermittently on 'browserstack:Google Pixel 7 Pro@13.0' and 'browserstack:chrome@112.0:OS X Ventura' and possibly some other chromium based desktop browsers.

We are using TestCafe 2.6.0 in proxy mode with --disable-web-security set in BROWSERSTACK_CHROME_ARGS