cy.click() doesn’t select element in custom dropdown component

[Sharan-ram]

Current behavior:

With the update to 3.5.0, Cypress doesnt seem to select the right MenuItem from the Material ui Popper. The cy.click() is applied to the right element but the actual element clicked is wrong. I have made a sample demo app reproducing the issue and a screenshot has been attached below:

Desired Behaviour:

cy.click() should be applied to the right element

Steps to reproduce:

Here is a sample repo which reproduces the issue. Run npm run cypress:open, select app.test.js file, you can see on the console that applied to is different from actual element clicked.

Versions

Cypress 3.5.0, reproducible even in v3.6.1
Browser Chrome

[sepehr500]

I have the same issue.

[jennifer-shehane]

The actual assertion should be checking the value, as this will fail whether the component selects properly or not, so change your last assertion to:

cy.get("[name=foods]").should("have.value", "Beef");

Regardless, this is a regression that was introduced in 3.5.0 and has not been fixed as of 3.8.1.

Repro

Run this repo: https://github.com/Sharan-ram/cypress-bug-demo and change last assertion to

cy.get("[name=foods]").should("have.value", "Beef");

3.4.1

3.5.0

All of the mouse click events seem to be happening on html.

3.8.1

3.8.1 indicates the exact same mouse event behavior

Workaround

Downgrade to 3.4.1 of Cypress.

[vramana]

@jennifer-shehane I did some digging into this issue yesterday.

https://github.com/cypress-io/cypress/blob/develop/packages/driver/src/cy/commands/actions/click.js#L157

mousemove event on the targetElement causes it to recompute it's position and it looks something like this.

So for the rest of the command the popover just stays towards the left we click on html element.

I did this testing with master branch. I have not checked what happens in 3.4.1

[jennifer-shehane]

Ran across this other issue with material-ui today, thought I would comment in case it sheds some light. #5826 (comment)

[stevenvachon]

Even with a should('contain', 'text'), it doesn't throw, so it must have the correct element selected, but continues to click the wrong one. What's worse is that it alternates; the first run through, it works as expected while the second has this issue. The results continue to alernately repeat through the third, fourth, etc runs.

Per comments in #6165, I can confirm that .click({ force: false}) makes it work.

Turns out that I just had to wait(2000) (until #1296) after clicking for an asynchronous module to load, which was causing some weird rendering issues.

[jennifer-shehane]

This issue still exists in Cypress 4.10.0.

[sainthkh]

I confirmed that the behavior @vramana said is true. 'mousemove' event does move autocomplete window to the left.

This behavior didn't happen before 3.5.0 because mousemove event wasn't supported. (It's added with #3030.)

When you comment out the line below:

cypress/packages/driver/src/cy/mouse.js

Line 362 in 4977450

events.push({ type: 'mousemove', ...mousemove() })

The test works correctly.

And the 'mousemove' event is sent at:

cypress/packages/driver/src/cy/mouse.js

Line 726 in 4977450

const preventedDefault = !el.dispatchEvent(evt)

---

This 'mousemove' event changes the style of popper. It removes the transform:

Before mousemove:

After mousemove:

And these values are computed by computeStyle at:

https://github.com/popperjs/popper-core/blob/0a2329323252fd287f263c28951883b35095082a/packages/popper/src/modifiers/computeStyle.js#L88

[sainthkh]

I found the cause. It's because of the click event simulation.

In native settings, the code flow after clicking menu is like this:

destroy
Popper constructor
update() with isDestroyed false
pointerdown event
mousedown event
update() with isDestroyed false
pointerup event
mouseup event
click event
destroy
update() with isDestroyed true => update is ignored

In Cypress settings, the code flow is like this:

destroy
Popper constructor
pointerdown event
mousedown event
pointerup event
mouseup event
click event
destroy
update() with isDestroyed true => update is ignored

As you can see, update() is not called. That's why the element is not relocated below the text field.

Although we know what the problem is, the solution is a bit hard. We need to give time for browsers to execute event handlers after an event is fired. To do so, we might need to restructure actionability.

Maybe, native event(#311) can be the solution.

[binary-koan]

In case this helps anyone else, my workaround for Material UI Autocomplete is to use keyboard controls to select the item. For example, to select the first item:

cy.get('.my-material-autocomplete input').type('{downarrow}{enter}')

[ashetty-womply]

@binary-koan 's solution worked for me.
I have an autocomplete field for state. Using {enter} worked.

cy.get("#state").clear().type('New {downarrow}{downarrow}{enter}');

[wanderleydrumond]

I also have the same issue with version 8.2.0.
I also tried cy.select() unsuccessfully.

[GarrisonD]

Also for Cypress 10.3.1

[GarrisonD]

Passing force: true to .click() solves the issue.

According to the docs the force option controls waiting for actionability.
Why doesn't Cypress throw an error about an un-actionable element then?

[roger-ngx]

Passing force: true to .click() solves the issue.

According to the docs the force option controls waiting for actionability. Why doesn't Cypress throw an error about an un-actionable element then?

this works with my popper

[cypress-app-bot]

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

[cypress-app-bot]

This issue has been closed due to inactivity.