Dynamically-created iframe with the `file:` protocol is not loading properly

[drrnkin]

What is your Scenario?

A test loads a page that dynamically inserts an iframe. element and loads that content. The iframe fails to be recognized.

What is the Current behavior?

In Chrome, the iframe can be seen to load correctly (if you watch), but TestCafe can't detect this and issues the message "Content of the iframe in which the test is currently operating did not load.". Note that in versions 1.x and 2.x Chrome worked correctly, but it's changed in 3.x.

What is the Expected behavior?

Simple test at https://github.com/drrnkin/testcafe-iframe should pass. The test should detect the content in the iframe that is dynamically created by a script in the iframe. Note that the test passes in Chrome in TestCafe 1.x or 2.x, but not 3.x.

Expected: test should pass in both Chrome and Firefox. Note that there's a related bug for Firefox #7991

What is your public website URL? (or attach your complete example)

https://github.com/drrnkin/testcafe-iframe

What is your TestCafe test code?

See provided repo

Your complete configuration file

See provided repo

Your complete test report

No response

Screenshots

No response

Steps to Reproduce

1. Clone the repo https://github.com/drrnkin/testcafe-iframe
2. yarn
3. yarn build
4. yarn test-chrome

TestCafe version

3.3.0

Node.js version

v16.20.2

Command-line arguments

See Steps to Reproduce

Browser name(s) and version(s)

Chrome 116.0.5845.111 (currently latest)

Platform(s) and version(s)

Windows 10

Other

No response

[ridginald]

+1 on this - macOs experiences the same issue, and prevents us from having all our jobs running on the testcafe same version

[AlexKamaev]

Please modify your example a little. Try to remove file system paths from the page property in the test and from the iframe src attribute as follows:

.page("http://localhost:8080/hostApp.html")

createIframe(document.body, "http://localhost:8080/iframe.html")

Then, please launch the http-server module from your project directory.

npx http-server

It is working on my side. As for the FF error, I've reproduced it as well. However, I cannot give any estimates on when the issue with FF will be resolved. We can research the FF issue. However, we need to have a simpler testcafe-iframe-bundle.js file to debug it efficiently.

[drrnkin]

There are no file system paths per se since all paths are relative (but you're right that the original ends up being a local file URL). Starting the server and changing the path to .page("http://localhost:8080/hostApp.html") indeed does not suffer the problem in Chrome.. However, simply describing something else that doesn't suffer from the bug doesn't negate the fact that there's a bug as originally described 😃

The provided test case worked fine in Chrome in 1.x and 2.x so this is a regression. You can see this by running yarn add testcafe@2 and then yarn test-chrome again, which passes in 1.x or 2.x. If you are saying that local URLs are not supported by TestCafe 3.x, please point me to the docs that describe this breaking change. Otherwise, the Chrome bug as described still stands.

As for the Firefox issue being difficult to deal with, the main.ts file simply imports Highcharts (a popular charting library: https://www.highcharts.com/) and that's enough to cause the issue. I don't have the source so I can't whittle it down further. All I can say is it has something to do with querySelectorAll as per the console error.

[AlexKamaev]

I agree that the described behavior is not expected, so we can consider it as a bug. I recommend that you use the described workaround until the issue is fixed.

As for the FF issue, please create a separate ticket using the following link: https://github.com/DevExpress/testcafe/issues/new?assignees=&labels=TYPE%3A+bug&projects=&template=bug_report.yaml.

[drrnkin]

OK thanks, I trimmed this one to not mention Firefox, and created a Firefox-specific bug at #7991.

[drrnkin]

FYI I noticed you added the "HAS_WORKROUND" flag. The workaround does indeed work around the issue, but we wouldn't be able to use it in our context, so this bug prevents us from upgrading to 3.x.

[AlexKamaev]

@drrnkin We understand your point, so that's why we consider this issue a bug. Even though we use this label to plan our workload, the HAS_WORKAROUND flag does not mean that we ignore the issue.

[AlexKamaev]

I researched the issue and found that it can be resolved by adding the --allow-file-access-from-files flag to your Chrome browser as follows:

testcafe "chrome --allow-file-access-from-files" test.js

I checked your usage scenario, and it works as expected. Please try to use this approach and share your results with us.

[drrnkin]

Yes, that workaround did pass for me. To be clear I locally modified the provided sample as follows (escaped quotes are important).

    "test-chrome": "testcafe \"chrome --allow-file-access-from-files\" tests",

and then ran "yarn test-chrome".

Some points to consider:

1. The iframe works without that flag when loaded manually in a browser, but not in TestCafe 3.x
2. It worked in TestCafe 2.x without that flag.
3. It would be difficult for us to apply the workaround across many small repos, not to mention other browser types would probably need similar workarounds.

[AlexKamaev]

1. Yes. TestCafe injects a lot of client script code to the page to communicate between the browser and the TestCafe server. Browser does not allow this code to work correctly when you use iframes with the file: protocol.

2. In version 3.0 and newer, TestCafe runs tests with the Native Automation option enabled by default. In Native Automation mode, TestCafe does not use the URL rewriting mechanism as in the previous version. Previously, TestCafe rewrote URL, so even files were opened under http protocol. If you want, you can use the --disable-native-automation flag or the corresponding property in config file to disable Native Automation.

3. We'll discuss the issue with the team. However, we cannot recommend any other solution at this time.

other browser types would probably need similar workarounds

Please note that Native Automation mode is enabled only in Chromium-based browsers (Chrome, Edge, etc.). You don't need to add this option to other browsers.

[drrnkin]

Thanks, I confirmed that creating a .testcaferc.json file with the content you referenced is another workaround.

{
    "disableNativeAutomation": true
}

Just a suggestion -- I wonder if TestCafe could automatically disable that feature by itself when it encounters a file:// url?

[AlexKamaev]

I'm happy to hear that the workaround resolved the issue for now.

I wonder if TestCafe could automatically disable that feature by itself when it encounters a file:// url

TestCafe cannot disable that feature automatically. However, we will discuss how to improve user experience with the Native Automation mode.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for a long period. It will be closed and archived if no further activity occurs. However, we may return to this issue in the future. If it still affects you or you have any additional information regarding it, please leave a comment and we will keep it open.

[drrnkin]

Commenting to remove stale state

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for a long period. It will be closed and archived if no further activity occurs. However, we may return to this issue in the future. If it still affects you or you have any additional information regarding it, please leave a comment and we will keep it open.

[github-actions[bot]]

We're closing this issue after a prolonged period of inactivity. If it still affects you, please add a comment to this issue with up-to-date information. Thank you.