AlexKamaev

We discussed the issue with the team once again and decided to keep it open in order to track user interest.

@wombatka At present, we cannot give any precise estimates on when TestCafe will support any other browsers except Chromium-based.

Could you elaborate on what you mean by popup window? Do you mean a real browser window or just some kind of DOM element with a fixed/absolute position? Please share...

@tandreys In this case, the only workaround is to use the `--disable-native-automation` option to disable the Native Automation mode.

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: ```JS .page("http://localhost:8080/hostApp.html") ```...

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....

@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...

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...

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...

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...