Wrong document referrer while using Chrome 89

[wfalowski]

What is your Test Scenario?

Hi,
we use testcafe for our E2E tests, everything was fine until our CI updated Chrome version to 89. We have one test which tests our embed widget which is injected into HTML as iframe via our SDK scripts. Our embed communicates with SDK scripts that's why we check if document.referrer for ou embed is same as event.origin (in window.parent.postMessage event which comes to the widget) - to avoid any security vulnerabilities.

To do the test we start web server on 3009 port, this web server returns HTML with our SDK and all data needed to initialize widget. Then our SDK script injects iframe which point to our main application on 3000 port. Then iframe communicates with parent document which should initialize widget and here we have an issue. Document referrer should point to http://localhost:3009/ instead it point to dynamic testcafe url (for example: http://192.168.1.231:53152/), without running tests by testcafe widget in latest version of Chrome works as expected.

Before Chrome update everything was fine (previous version which wasn't failing 86), on the other hand Safari works as should and document.referrer points to proper address inside our iframe. I attached screenshots with logs from both Chrome, Chrome - testcafe runner and Safari - testcafe runner.

What is the Current behavior?

document.referrer inside iframe point to wrong address.

What is the Expected behavior?

document.referrer inside iframe should point to our test server address.

What is your web application and your TestCafe test code?

Your website URL (or attach your complete example):

Example app with SDK: https://adoring-roentgen-3ac020.netlify.app/

Your complete test code (or attach your test files):

 const iframe = Selector('.omni-calculator-frame');

test('Should have working iframe.', async t => {
  await t.switchToIframe(iframe);
});

Your complete configuration file (if any):

{
  "clientScripts": [
    { "module": "@testing-library/dom/dist/@testing-library/dom.umd.js" }
  ]
}

Your complete test report:

1) The element that matches the specified selector is not visible.

      Browser: Chrome 89.0.4389.128 / macOS 11.2.3

         28 |  .page(`http://127.0.0.1:${STATIC_SERVER_PORT}/embed-with-margin.html`);
         29 |
         30 |const iframe = Selector('.omni-calculator-frame');
         31 |
         32 |test('Should have iframe with functioning calculator.', async t => {
       > 33 |  await t.switchToIframe(iframe);
         34 |});
         35 |

Screenshots:

Chrome 89 without testcafe runner

Chrome 89 running by testcafe.

Safari running by testcafe

Steps to Reproduce:

1. Go to my example app using Chrome
2. You see our widget working properly
3. Run same website using testcafe and latest Chrome version
4. You see that our widget is empty (because of problem described above)

Your Environment details:

• testcafe version: 1.12
• node.js version: 14.13.0
• command-line arguments: testcafe chrome OurTest.test.js --debug-mode
• browser name and version: Chrome 89, Safari 14.03
• platform and version: macOS 10.15.6

[viktoria2506]

Hello,

Could you please check your scenario with the latest TestCafe version? If the issue persists, please let us know. We will look into this.

[wfalowski]

Hi, thank you for quick response. Unfortunately, the same issue occurs with latest testcafe version 1.14. I would be very grateful for checking this problem. Thank you 🙇

[wentwrong]

Thank you for the detailed explanation and the example. I reproduced the issue with the incorrect document.referrer value in an iframe document. We'll look into this.

For the team:
Run the code below, navigate Hammerhead Playground to the http://localhost:3009/ page. After that, in the browser console, you will see the http://localhost:1401/ address (of our proxy) logged, instead of http://localhost:3009/ (which is the address of the actual referrer).

require('http')
    .createServer((req, res) => {
        if (req.url === '/') {
            res.writeHead(200, { 'content-type': 'text/html' });
            res.end(`
                <!DOCTYPE html>
                <head>
                    <link rel="shortcut icon" href="#" />
                </head>
                <body>
                <script>
                    var iframe = document.createElement('iframe');

                    iframe.src = 'http://localhost:3000/iframe';
            
                    document.body.appendChild(iframe);
                </script>
                </body>
            `);
        } else
            res.destroy();
    })
    .listen(3009, () => console.log('http://localhost:3009/'));

require('http')
    .createServer((req, res) => {
        if (req.url === '/iframe') {
            res.writeHead(200, { 'content-type': 'text/html' });
            res.end(`
                <!DOCTYPE html>
                <body>
                    <script>
                        console.log(document.referrer);
                    </script>
                </body>
            `);
        } else
            res.destroy();
    })
    .listen(3000, () => console.log('http://localhost:3000/iframe'));

[blazeej]

Hi,
I ran into the same problem when upgrading testcafe/testcafe docker image from 1.13.0 to 1.14.0.
Version 1.13.0 comes with firefox 85.0, which has no problem with document.referrer. Version 1.14.0 comes with firefox 87.0, which has the problem described in this issue.

Is there any workaround for this problem?

[AlexKamaev]

@blazeej Thank you for additional information. I managed to reproduce the issue in the latest (90) Firefox version. For now, there is no workaround. Please track this thread to get updates.

[ash1425]

I have the same problem where referer and host headers are sent that of hammerhead proxy. Any guidance on how to fix it ?
I have a third party Iframe which will not accept the hammerhead proxy host.

[Aleksey28]

Hi @ash1425,

This issue was resolved. So, your case seems to be different. Please follow this instruction and share your simple sample: https://testcafe.io/402636/faq#how-to-create-a-minimal-working-example-when-you-submit-an-issue.