App window does not respond to mouse events in window focus race condition

[sync-by-unito[bot]]

https://user-images.githubusercontent.com/1271364/171277456-f5201f5a-0703-4111-8668-8f198cae8a5d.mov

Browsers

All browsers, EXCEPT for Electron because Electron is launched in the same docked application as Cypress

Operating Systems and Hardware

• Reproduced on OSX Monterey w/ M1 Chip
• Could not reproduce on OSX Catalina w/ Intel Chip
• Reproduced intermitently on Monterey with intel Chip

Steps to reproduce

1. Click "start component testing" with Chrome browser
2. IMMEDIATELY move your cursor (don’t click/change focus) onto where the window will open.
3. Again, do not click anything

Observe: hover states don’t work, pointer states aren’t working, you have to click 2-3x for any clicks to register

Workaround: Once you Cmd + Tab/lose focus to another docked application, everything will work again

This does not happen in Electron because it shares the same Docked Application with Cypress.

┆Issue is synchronized with this Jira Bug by Unito ┆Attachments: Screen Recording 2022-03-11 at 6.07.14 PM.mov | Screen Recording 2022-04-21 at 1.34.59 PM.mov ┆author: Shawn Taylor ┆epic: Edge Cases ┆friendlyId: UNIFY-1172 ┆priority: Low ┆sprint: Unification Hardening ┆taskType: Bug

[sync-by-unito[bot]]

➤ Bart Ledoux commented:

Could this be a chrome issue on M1 macs?

It is either this or an infinite loop.

[sync-by-unito[bot]]

➤ Shawn Taylor commented:

it doesn’t seem like an infinite loop since it always resolves when i switch to another app and back

[sync-by-unito[bot]]

➤ Shawn Taylor commented:

i just tried to reproduce this and am currently unable to 🤷

[sync-by-unito[bot]]

➤ Jess Sachs commented:

I’m also getting this issue but have no idea why it’s happening.

[sync-by-unito[bot]]

➤ Bart Ledoux commented:

I will check on intel if it is an issue as well

[sync-by-unito[bot]]

➤ Shawn Taylor commented:

i was able to reproduce this again today, both in chrome and firefox. i’m on an M1 Mac.

[sync-by-unito[bot]]

➤ Bart Ledoux commented:

It behaves exactly like if chrome could not get focus

[sync-by-unito[bot]]

➤ Lachlan Miller commented:

Has anyone seen this on a non M1 machine?

[sync-by-unito[bot]]

➤ Shawn Taylor commented:

Lachlan Miller assuming that the issue Robert Guss is seeing ( https://cypressio.slack.com/archives/C02MW5QBD4K/p1644243428945549 ) is the same, then yes. he’s on a non-M1 Mac.

[sync-by-unito[bot]]

➤ Lachlan Miller commented:

Shawn Taylor Gonna wait for a confirmation before going on a wild goose chase. 😅

[sync-by-unito[bot]]

➤ Lachlan Miller commented:

Looks like Robert has seen on non M1 but w/o a consistent reproduction it’s hard to really pick this up.

[sync-by-unito[bot]]

➤ Tim Griesser commented:

Is this this issue primarily coming up on M1 macs? If so, based on google results for “chrome hanging m1” it seems like maybe this is more of a Chrome issue

https://www.reddit.com/r/mac/comments/qjhmp7/chrome_crashing_on_m1_pro/ ( https://www.reddit.com/r/mac/comments/qjhmp7/chrome_crashing_on_m1_pro/|smart-link )

https://www.getdroidtips.com/fix-chrome-crash-m1-m1-max/#6-Disable-Hardware-Acceleration-in-Chrome ( https://www.getdroidtips.com/fix-chrome-crash-m1-m1-max/#6-Disable-Hardware-Acceleration-in-Chrome|smart-link )

The second link above mentions disabling hardware acceleration might help. Seems we do that on linux with --disable-gpu flag: https://github.com/cypress-io/cypress/blob/f79bdd665ada815fbfa238baac7a66c38d3b5d82/packages/server/lib/browsers/chrome.ts#L388-L390 ( https://github.com/cypress-io/cypress/blob/f79bdd665ada815fbfa238baac7a66c38d3b5d82/packages/server/lib/browsers/chrome.ts#L388-L390|smart-link ) maybe we should see if we should also be doing this on M1?

Jess Sachs / Bart Ledoux / Shawn Taylor can you reliably reproduce / see if always toggling this flag gives any improvement?

Should be able to use before:browser:launch

on('before:browser:launch', (browser = {}, launchOptions) => {
  if (browser.name === 'chrome') {
    launchOptions.args.push('--disable-gpu')
  }
})

[sync-by-unito[bot]]

➤ Lachlan Miller commented:

People encountering this: is it a chrome only issue? Maybe try firefox for a few days to fully isolate; the ticket description might need to be “App window is sometimes not interactive in chrome”?

[sync-by-unito[bot]]

➤ Bart Ledoux commented:

Shawn Taylor had it on Firefox last time we tried

[sync-by-unito[bot]]

➤ Jess Sachs commented:

I’ve isolated this issue a bit more….

1. Happens on every non-electron browser (FF, Edge, Chrome Canary, Chrome, etc)

To reproduce…

1. open a browser
2. IMMEDIATELY move your mouse via trackpad (don’t click/change focus) onto where the window will open.
3. Again, do not click anything

Observe: hover states don’t work, pointer states aren’t working, you have to click 2-3x for any clicks to register

4. Once you Cmd + Tab/lose focus to another tray application, everything will work again

You must move your mouse before the browser has fully opened to reproduce this issue.

[sync-by-unito[bot]]

➤ Bart Ledoux commented:

In what I see in the video below, taken on intel (Monterrey) it has to do with movement of the cursor before focus. Just moving your mouse over the window to focus and wait does not trigger the issue.

Screen Recording 2022-03-11 at 6.07.14 PM.mov

[sync-by-unito[bot]]

➤ Bart Ledoux commented:

On M1 I see this issue more when I set my mouse towards the top of the app instead of towards the list.

Note: it could very well be a coincidence. The top is further from the open button than the list so it need s me to further with the cursor.

[sync-by-unito[bot]]

➤ Jess Sachs commented:

I was able to reproduce this on Cypress 9 on my machine. It may be a Monterey issue.

I think we should deprioritize this issue Chris Baus and pick up something else.

[sync-by-unito[bot]]

➤ Shawn Taylor commented:

this still happens to me often enough to be annoying 😕 and would probably really confuse me if i didn’t know i can just switch windows to fix it

[sync-by-unito[bot]]

➤ Tim Griesser commented:

Reopened but marked as low priority so we don’t lose track of it

[sync-by-unito[bot]]

➤ Jake Herbst commented:

This happens for me as well using the Chrome(v100) browser

Screen Recording 2022-04-21 at 1.34.59 PM.mov

Running: https://cdn.cypress.io/beta/npm/10.0.0/darwin-x64/10.0-release-c110aa19412ca42c6f83fd87acca81729f955af9/cypress.tgz ( https://cdn.cypress.io/beta/npm/10.0.0/darwin-x64/10.0-release-c110aa19412ca42c6f83fd87acca81729f955af9/cypress.tgz ) Apple Macbook Pro - MacOS Monterey - Apple M1 Max chip

I can reproduce consistently using the steps Jess outlined in https://cypress-io.atlassian.net/browse/UNIFY-1172?focusedCommentId=16933 ( https://cypress-io.atlassian.net/browse/UNIFY-1172?focusedCommentId=16933|smart-link )

[sync-by-unito[bot]]

➤ Bill Glesias commented:

I also ran into this in Firefox 99 on MacOS Monterey with intel Chip. Also appears to be intermittent and was able to open dev tools but clicking on specs and other items in the UI had no effect.

[Zach-Costa]

I can reproduce this consistently on my Macos Monterey with Intel chip!

[mapsandapps]

I just reproduced in Firefox again. This is not a Chrome-specific bug.

https://user-images.githubusercontent.com/14926794/195631210-de6c94cf-aa2d-4ffb-84c7-311dd09beca3.mov

Edit:

Workarounds to avoid the issue:

1. Use Electron
2. Try not to move your mouse cursor between when you click to select a browser and when the browser window opens. It seems the cursor movement is what triggers the bug, and avoiding moving your cursor should prevent the bug from happening.
3. If the bug does occur, command-tab (or click, etc.) out to any other window and then back in to allow the window to respond.

[lmiller1990]

This is going to come up more when people use the new Run All Specs experiment, we should look at solving this soon.

[rockindahizzy]

Hey team! Please add your planning poker estimate with Zenhub @amehta265 @astone123 @lmiller1990 @marktnoonan @mike-plummer @warrensplayer @ZachJW34

[lmiller1990]

Word on the street is that @brian-mann has a fix, let's follow that up before anyone does any additional work here.

[lmiller1990]

I found out Cypress 9 has the same problem. Notice I need to spam click to get the browser to focus. I think this bug must be related to a recent MacOS version. Too bad it's impossible to downgrade MacOS versions and find out exactly when this was introduced.

Video:

https://user-images.githubusercontent.com/19196536/204700366-7d52099f-efa9-4eed-ad98-667a7340e7d0.mov

[lmiller1990]

Ok - this is not Cypress specific, I reproduced in a bare-bones electron app:

https://user-images.githubusercontent.com/19196536/204917681-569f4a22-382f-4334-b589-9048c036c857.mov

[lmiller1990]

Electron issue: https://github.com/electron/electron/issues/36506

[lmiller1990]

Actually... maybe nothing to do with Electron, but a MacOS bug. I reproduced with a regular Node.js program. It's more obvious with Cypress - basically, the longer you wait and the more you spam move your mouse, the worse the delay gets.

{
  "name": "electron-quick-start",
  "version": "1.0.0",
  "description": "A minimal Electron application",
  "main": "main.js",
  "scripts": {
    "start": "electron ."
  },
  "repository": "https://github.com/electron/electron-quick-start",
  "keywords": [
    "Electron",
    "quick",
    "start",
    "tutorial",
    "demo"
  ],
  "author": "GitHub",
  "license": "CC0-1.0",
  "devDependencies": {
    "electron": "^22.0.0"
  },
  "dependencies": {
    "chrome-launcher": "^0.15.1"
  }
}

const ChromeLauncher = require("chrome-launcher");

const wait = () => new Promise(res => setTimeout(res, 2000))

async function main () {
  await wait()
  ChromeLauncher.launch({
    startingUrl: "https://google.com",
  }).then((chrome) => {
    console.log(`Chrome debugging port running on ${chrome.port}`);
  });
}

main()

https://user-images.githubusercontent.com/19196536/204924265-8a776010-99c7-497b-b86c-354fa49918af.mov

[lmiller1990]

I'm moving this to blocked until we decide how we want to progress. A work-around is possible - that would be programatically change to the electron app and back to the browser after launching, but you get a flicker of the electron app, which looks a bit unpolished. The core bug is not in Cypress, but in MacOS Monterey and above, but I don't think Apple will be fixing this any time soon.

[pherrymason]

I've stumbled into this issue while having this same problem while developing a rust application under a M2 chip on Monterrey.

• https://github.com/not-fl3/macroquad/issues/422

Also seeing the same problem on other repositories: https://github.com/love2d/love/issues/1582

Everything points this is a OS bug.

[jennifer-shehane]

Closing since there's nothing actionable on our side for this.