TestCafe is disconnecting from the browser upon login - [ERROR]: browser disconnected. If you did not close the browser yourself, browser performance or network issues may be at fault.
See original GitHub issueWhat is your Scenario?
Login to Heroku , reach main page.
The behaviour of the browser with TestCafe differ from regular usage (Tested with multiple browsers and TC versions)
After we will try to login the connection of TC and the browser is lost. TC will try to execute 2 more times till we will fail.
What is the Current behavior?
Fail to login and loopback to login page while testcafe loses the connection to the browser
What is the Expected behavior?
Login will pass and we will reach main Heroku page
What is your public website URL? (or attach your complete example)
What is your TestCafe test code?
import { Selector, ClientFunction } from 'testcafe';
const textinputEmailAddress = Selector('[name=\'email\']');
const textinputPassword = Selector('[name=\'password\']');
const buttonSubmit = Selector('[type=submit]');
const headingPrimary = Selector('h2').withText('Log in to your account');
fixture `Heroku login failure fixture`
.page('https://id.heroku.com/login');
test('Login to heroku', async t => {
await t.expect(headingPrimary.exists).ok('The \'Login\' page title', { timeout: 10000 });
await t
.typeText(textinputEmailAddress, ANY-USER, { replace: true, paste: true })
.typeText(textinputPassword, 'ANY-USER-PASS', { replace: true, paste: true })
.click(buttonSubmit);
console.log('click on later button');
const buttonLater = Selector('button').withText('Later');
await t.click(buttonLater);
console.log('verify we looped back to login, instead of reaching https://dashboard.heroku.com/apps');
await t.expect(headingPrimary.exists).ok('The \'Login\' page title', { timeout: 10000 });
});
Your complete configuration file
no config required in this example: testcafe chrome ./automation/tests/testcafe_disconnect_reproduction.ts
Your complete test report
Heroku login failure fixture "click on later button verify we looped back to login, instead of reaching https://dashboard.heroku.com/apps "click on later button verify we looped back to login, instead of reaching https://dashboard.heroku.com/apps "click on later button verify we looped back to login, instead of reaching https://dashboard.heroku.com/apps ERROR The Chrome 99.0.4844.83 / macOS 10.15.7 browser disconnected. If you did not close the browser yourself, browser performance or network issues may be at fault.
Screenshots
No response
Steps to Reproduce
1.Create a free Heoku user 2.Update credentials in the shorten example I supplied 3.Execute the code example with testcafe chrome ./RELATIVE_PATH/FILE_NAME.ts
TestCafe version
1.18.1 (reproduced with 1.14.1 as well)
Node.js version
12/14/16
Command-line arguments
testcafe chrome ./RELATIVE_PATH/FILE_NAME.ts
Browser name(s) and version(s)
Chrome/FF/Safari
Platform(s) and version(s)
Mac/ubuntu
Other
Adding more debugging info upon failure will be great, why we lost the connection, what can be done to avoid etc.
Issue Analytics
- State:
- Created a year ago
- Reactions:2
- Comments:13 (3 by maintainers)
Top GitHub Comments
@yoavws, I confirm that this issue is not reproduced in v1.18.6. We made significant code changes between these versions.
@vlads11, I’m afraid we cannot give you any recommendations. To determine the cause of the issue, we need to reproduce and research it. So, feel free to create a new GitHub issue and share a minimal working example illustrating the problem: How To: Create a Minimal Working Example When You Submit an Issue.
You can use the following template to create the GitHub issue: Issue Template.
We are closing this issue since it is not reproducible in v1.18.6.
In another inspection into the exception. It seems the site(Heroku) or some where in hammerhead we get: 2022-03-31T16:26:18.488Z hammerhead:proxy Proxy request peGyY7Sa9 GET /Xrhq9HRjC!s!utf-8/https:/dashboard.heroku.com/assets/dashboard-7637d7a128b471b8fbdef430fedda9dd.map
the proxy crash is seems to be crashing due to the protocol scheme typo: we get https:/ instead of https://
from testcafe execution we get the same: