cy.click() yields no error, but wrong element is clicked

[badeball]

I previously reported erroneous behavior in regards to determining visibility. With #6000 and v3.8.2, this was indeed fixed, but it uncovered another issue.

Current behavior:

cy.get("...").click({ force: false }) no longer yields an error, but the click-handler of the DOM element is never invoked. If I however invoke it with force: true, its click-handler is invoked.

I modified Cypress with the patch shown below and was quite surprised to find that the actually clicked element is not the element described in the console as "Actual Element Clicked". The actual element clicked is an ancestor of my subject, which does not have any click-handler at all.

diff --git a/packages/driver/src/cy/commands/actions/click.js b/packages/driver/src/cy/commands/actions/click.js
index f6e0cb7f5..c4add683e 100644
--- a/packages/driver/src/cy/commands/actions/click.js
+++ b/packages/driver/src/cy/commands/actions/click.js
@@ -207,6 +207,8 @@ module.exports = (Commands, Cypress, cy, state, config) => {
         onReady (fromElViewport, forceEl) {
           const clickEvents = mouse.click(fromElViewport, forceEl)
 
+          console.log(clickEvents);
+
           return {
             clickEvents,
           }

Desired behavior:

If cy.get("...").click({ force: false }) doesn't yield an error, it should invoke the click-handler of the subject and not some other element determined by some heuristic.

Test code to reproduce

I'm having a hard coming up with a minimal example to reproduce the issue. I'm posting the output of the commands in hope that it will be enough to spark some ideas. If this is not enough, then I'll give it another shot.

With force: false:

With force: true:

Versions

Cypress v3.8.2, Arch Linux, Chrome 79.

[badeball]

Gosh, looking through the changelog and I see that this has been troublesome for a while.

I've added some waiting to my tests to ensure that there's no animation going it, but the problem still resides.

[jennifer-shehane]

The idea behind this behavior is to mimic the behavior that the browser enforces when a real user clicks.

If a user in a real browser clicks on an element and mid-click another DOM element animates in front of where their mouse cursor is, the rest of the Mouse events will fire on the new element that is now directly behind the mouse cursor.

This is expected behavior with the correct workaround being to use force: true as you've noted which will force all Mouse events to be triggered on the DOM element specified.

I can see how the 'Actual Element Clicked' console log is a bit confusing though since some of the events were fired on another element.

That being said, there could be some weird edge case where this is doing funky things outside of what I just described. If that is the case - we'll need a reproducible example provided to investigate.

[badeball]

Alright, I understand. There's without a doubt a discrepancy between browser-behavior and Cypress-behavior in my case. I will see if I can create a minimal example. For those curious, it's related to Google Maps and overlays.

[badeball]

I've added a minimal example here. The example-application will zoom the map upon clicking the marker. In Cypress, this only works with force: true, which is what I believe to be erroneous.

Unforunately, this entails google maps, as mentioned above. Hence, 1) the example is somewhat cluttered from technical point of view and thus not "minimal" and 2) it requires an API key to run.

Do you posses a key yourself to make it run?

If not, I am able to host the example at a hidden location which I can provide you in confidence (due to API restrictions). You can contact me on jonasba on Gmail.

[vramana]

Possibly related to #5805

[sainthkh]

Can you check if { force: true } works with 4.12.1 and API key empty?

With my Ubuntu 20.04, it doesn't work.

Only manual click works in this setting.

[badeball]

Can you check if { force: true } works with 4.12.1 and API key empty?

With my Ubuntu 20.04, it doesn't work.

Yes, I can check. FYI, in your screenshot, it appears you are not using force: true.

• With v5.5.0 and force: false: wrong element is clicked
• With v5.5.0 and force: true: correct element is clicked
• With v4.12.1 and force: false: wrong element is clicked
• With v4.12.1 and force: true: correct element is clicked
• With v3.4.0 and force: false: correct element is clicked
• With v3.4.0 and force: true: correct element is clicked

IE. there's a regression somewhere after v3.4.0.

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