typeText with Chrome 75 types each character at beginning of input

[highspotjeremy]

What is your Test Scenario?

Type text into a text input field in our application using the typeText action.

What is the Current behavior?

With Chrome 74, the text is typed correctly. With Chrome 75 (updated today), the characters are typed, but the cursor moves to the start of the input with each character, so the typed text is in the reverse order.

What is the Expected behavior?

Text typed into the input is in the correct order.

What is your web application and your TestCafe test code?

This is occurring with the sign-in for our application: https://app.highspot.com

Simplified test:

 import { Selector } from 'testcafe';

const inputEmail = Selector('.login-page #email', { timeout: 60000 }); // On first startup, login can take a while to appear
const inputPassword  = Selector('.login-page #password');
const buttonSubmit = Selector('.login-page button[type=submit]');

fixture(`Basic signin test`);

test(`Type text into email input`, async t => {
  await t.navigateTo(`https://app.highspot.com`);

  await t.typeText(inputEmail, 'test@highspot.com')
         .click(buttonSubmit);
  await t.expect(inputPassword.exists).ok();
});

Your complete test report:

Using locally installed version of TestCafe.
 Running tests in:
 - Chrome 75.0.3770 / Mac OS X 10.14.5

 Basic signin test
 ✖ Type text into email input

   1) AssertionError: expected false to be truthy

      Browser: Chrome 75.0.3770 / Mac OS X 10.14.5

          9 |test(`Type text into email input`, async t => {
         10 |  await t.navigateTo(`https://app.highspot.com`);
         11 |
         12 |  await t.typeText(inputEmail, 'test@highspot.com')
         13 |         .click(buttonSubmit);
       > 14 |  await t.expect(inputPassword.exists).ok();
         15 |});

         at ok (/Users/jeremy.klukan/github/nutella2/testcafe/tests/BasicSigninTest.js:14:40)



 1/1 failed (7s)

Steps to Reproduce:

1. Save the provided test code to test.js
2. Run testcafe with the following command: testcafe chrome test.js
3. Observe what happens when the test types in the e-mail address

Your Environment details:

• testcafe version: 1.2.0
• node.js version: 10.15.1
• command-line arguments: testcafe "chrome" --debug-on-fail tests/BasicSigninTest.js
• browser name and version: Chrome 75
• platform and version: macOS 10.14.5
• other: I ran this test with Google (https://www.google.com) and did not have any problems. I don't have an explanation for that. Slowing down the test run even to 0.1 does not alter the result. This works perfectly fine in Chrome 74 and below. OS does not seem to matter, as we use Travis for our CI building with Linux, and it began to fail there when the Chrome version changed from 74 to 75.

[Jakedavies]

I am noticing this too, testcafe fails to fill in our email field incorrectly

[Yastrenky]

looks like is only affecting the input type=email

[AlexKamaev]

Thank you for this information. The issue appeared after the Chrome update to the 75 version. We'll try to provide a fix soon.

[AlexKamaev]

While we are working on a fix, you can use the following workaround:

await t.typeText(inputEmail, 'test@highspot.com', { paste: true })

[highspotjeremy]

While we are working on a fix, you can use the following workaround:

await t.typeText(inputEmail, 'test@highspot.com', { paste: true })

@AlexKamaev - thanks for the quick response!

Regarding the workaround, I did try that (with success) before posting the issue. However, given the number of places in our test code that we use typeText, it's unfortunately not a viable option. In the interim, we have disabled our UI automation tests in Chrome, since we also cannot [easily] instruct Travis to use a specific Chrome version.

Thanks again!

[nobitagit]

Chiming in just to confirm that we are also experiencing the issue. A couple of points if that helps.

1. the issue is not limited to type=email but we're seeing it on type=number (so I'm not sure if the type makes any difference?)
2. the workaround works fine for now

Many thanks @AlexKamaev for being on top of this one and providing quick feedback.

@highspotjeremy did you try executing the test with another browser? Not sure it's applicable to your setup but just FYI you can switch to Firefox maybe?

[AlexKamaev]

Thank everybody for posting additional information about the issue. I found the cause of this behavior and hope to fix it soon.
 
@nobitagit You're right about input[type=number]. This is the same issue. So the fix will affect both the email and number types.

[byrne-greg]

confirming with @nobitagit; we've switched our tests from using HeadlessChrome 75 to Firefox (latest) on a travis build with success until the issue is resolved.

[PedroBorracho]

the proposed workaround did not work for me when using option
replace: true

I managed to do the cleanup with
await t.selectText(node).pressKey('delete');

[jbradensmile]

A less drastic workaround is to change the default browser when running your projects. Since this should be a temporary issue, I don't see a reason in altering the way we write our scripts due to this. As nobitagit brought up, is there a way in TestCafe to specify which version of a browser we want to run the project in? Something like "chrome:74"? Or in the configuration file: "browsers": { "browser": "chrome", "version": "74.*"}?

[helen-dikareva]

While there is no way to specify the browser version directly, you may specify a path to the browser with a required version

"browsers": "path:`C:\\Program Files\\PathToChrome74\\chrome.exe`"

I want to inform you that the fix (thanks to @AlexKamaev) for the original issue is ready and we're going to publish an alpha version today.

[uhinze]

FYI testcafe@1.2.1 is out now, including this fix

[highspotjeremy]

Verified, thanks all!

[highspotjeremy]

This still seems to be happening when doing mobile emulation. Here's the command where I'm seeing it:

testcafe "chrome:emulation:device=iphone x" tests

It works fine with desktop Chrome.

[AlexSkorkin]

@highspotjeremy, thank you for sharing your findings with us. Indeed, this issue still occurs when doing mobile emulation. We will look into it.

[mixman68]

Hello,

I still have issue with 1.2.1 and this code :

import { Selector } from 'testcafe';

fixture('Getting Started')
  .page('https://github.com');

test('Find "testcafe-example" repo on GitHub', async (t) => {
  const repo = Selector('.repo-list > li > div');
  // search github
  await t
    .typeText('form[action="/search"]', 'testcafe-example user:mjhea0')
    .pressKey('enter');
  // check li for results
  await t
    .expect(repo.innerText).contains('mjhea0/testcafe-example');
});

[AlexKamaev]

@djgreg13
I checked your example and it works as expected.
I've just added await t.maximizeWindow command. Otherwise the search input is not displayed.

test('Find "testcafe-example" repo on GitHub', async (t) => {
    const repo = Selector('.repo-list > li > div');
    // search github
    await t
        .maximizeWindow()
        .typeText('form[action="/search"]', 'testcafe-example user:mjhea0')
        .pressKey('enter');
    // check li for results
    await t
        .expect(repo.innerText).contains('mjhea0/testcafe-example');
});

In addition, I want to mention that this ticket is about input with types email or number, so it can not be the cause of your issue.

[mixman68]

@AlexKamaev,
on my side, the search input is already displayed, but chrome 75 as a strange behaviour with 1.2.1, but i don't have this strange behaviour with master repo, so seems to be fixed, i wait for future release :D, thanks you.

Chrome 74 works fine with 1.2.1, so i rollback my chrome ver while waiting the 1.2.2

[AlexKamaev]

@djgreg13
It's strange that you still have some issue in 1.2.1. Anyway, feel free to ask me if further TestCafe release does not help you.

[lock]

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.