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

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.

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

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.