chore: add GraphQL mutation for sending system notifications via Electron

[astone123]

• Closes Implement system notifications infrastructure #26687

Additional details

This PR adds a new GraphQL mutation and Electron action that allows us to send a system notification to the OS using the Electron notifications API. We've manually tested these notifications on macOS, Linux, and Windows operating systems:

macOS

https://www.loom.com/share/18a187afab884957af3245508a0f3de3

Windows

OUTSTANDING ISSUE
There is an issue on Windows where when a user clicks the action to turn off notifications for Cypress, the Cypress app does not appear in the Windows notification settings. This means that users cannot re-enable notifications for the Cypress app once they have been disabled this way at the OS level.

I suspect that this has to do with the way that Cypress is installed. Most applications have a Windows installer that sets up shortcuts for the applications, but Cypress doesn't do this because it is launched from the command line. We are discussing how to work around this or find a solution.

Created #26786 to deal with this

https://www.loom.com/share/faf661068e6d4391b128aa4525cd3054

Ubuntu

electron_notifications_ubuntu_poc.mov

Steps to test

You can test the notifications using the GraphiQL GUI

1. Run Cypress
2. Open a project in a browser
3. With Launchpad focused, click "Developer Tools" in the menu bar and select "GraphiQL"
4. Write a mutation

mutation showNotification($title: String!, $body: String) {
  showSystemNotification(title: $title, body: $body)
}

5. Add variables

{
  "title": "My notification",
  "body": "This is a test notification"
}

6. Press the play button to execute the query
7. Verify that Cypress sent a notification to your operating system (take action to allow notifications if needed)
8. Verify that clicking on the notification focuses your active browser window (not Launchpad)

How has the user experience changed?

This should not change the user experience because this mutation is not being executed anywhere in the app.

PR Tasks

• [na] Have tests been added/updated? I decided that it wouldn't be worth writing automated tests for this yet since it's not called yet. Once we use it somewhere, we can test it at that level instead
• [na] Has a PR for user-facing changes been opened in cypress-documentation?
• [na] Have API changes been updated in the type definitions?

[cypress]

10 flaky tests on run #46461 ↗︎

0

4832

909

0

10

Details:

feedback
Project: cypress	Commit: f48a0d2922
Status: Passed	Duration: 14:48 💡
Started: May 17, 2023 11:13 PM	Ended: May 17, 2023 11:28 PM

  runs.cy.ts • 1 flaky test • app-e2e

View Output Video

Test		Artifacts
App: Runs > Runs - Create Project > when a project is created, injects new projectId into the config file, and sends expected UTM params		Output Screenshots Video

  specs_list_latest_runs.cy.ts • 1 flaky test • app-e2e

View Output Video

Test		Artifacts
App/Cloud Integration - Latest runs and Average duration > when no runs are recorded > shows placeholders for all visible specs		Output Screenshots Video

  cypress-in-cypress-component.cy.ts • 1 flaky test • app-e2e

View Output Video

Test		Artifacts
Cypress In Cypress CT > default config > redirects to the specs list with error if a spec is not found		Output Screenshots Video

  cypress-origin-communicator.cy.ts • 1 flaky test • app-e2e

View Output Video

Test		Artifacts
Cypress In Cypress Origin Communicator > cy.origin passivity with app interactions > passes upon test reload mid test execution		Output Screenshots Video

  commands/net_stubbing.cy.ts • 2 flaky tests • 5x-driver-webkit

View Output Video

Test		Artifacts
... > with `times` > only uses each handler N times		Output Video
... > stops waiting when an xhr request is canceled		Output Video

The first 5 flaky specs are shown, see all 7 specs in Cypress Cloud.

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[mike-plummer]

@astone123 I was poking through the Electron notification docs and came across two things:

1. I noticed the Notification.isSupported() flag - any value in exposing this through, or checking it prior to attempting to show a Notification?
2. There's an additional close event that might be nice to allow consumers to register for (so they could know both when a notification was acted on (click) or dismissed (close)....but according to the docs it doesn't trigger in all circumstances so maybe not worth it. A partial event is sometimes worse than none at all

[astone123]

@mike-plummer

1. Yeah I saw this - I can't think of a scenario where this would return false, maybe if the user was on a super old OS. Not sure if Cypress would even run correctly on an OS that doesn't support notifications. Might be worth looking into in the future though.
2. We can definitely add this later if needed, but yeah that stood out to me in the docs. I wonder under what circumstances it wouldn't trigger the close event? Seems kind of vague. As of right now I don't think we have a use for it in this initiative

[mike-plummer]

/nit: Could avoid building this function if an onClick was provided to save a processor cycle:

const clickHandler = onClick || (async () => {
  await this.ctx.actions.browser.focusActiveBrowserWindow()
})

[cypress-bot]

Released in 12.14.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v12.14.0, please open a new issue.