ANR Detection Improvements Needed for Modal Dialog Handling

[smeubank]

Problem Statement

Summary

The current ANR (Application Not Responding) detection in the Electron SDK generates false positives when modal dialogs are shown, particularly on Windows. This leads to misleading non-responsiveness reports for intentional UI pauses.

Problem Description

When using modal dialogs (e.g., dialog.showSaveDialog) in Electron applications, the UI thread is intentionally blocked while waiting for user input. However, the ANR detection system interprets this as an application freeze and generates false positive reports.

Current Behavior

• ANR events are triggered after 5 seconds of UI thread blocking
• Modal dialogs that take longer than 5 seconds to dismiss trigger ANR reports
• No built-in way to distinguish between actual freezes and intentional modal pauses
• High volume of false positives in common scenarios

Expected Behavior

The ANR detection should:

1. Automatically detect and handle system modal dialogs
2. Provide API to temporarily disable ANR detection during known modal operations
3. Include context about foreground window/process ownership in ANR reports
4. Distinguish between intentional UI blocks and actual application freezes

Solution Brainstorm

1. Automatic Detection:

   • Detect when foreground window is owned by system process
   • Skip ANR reporting in these scenarios

2. API Improvements:

   • Expose methods to manually pause/resume ANR detection
   • Allow configuration of modal dialog handling
   • Provide hooks for custom modal detection logic

3. Enhanced Context:

   • Include foreground process information in ANR reports
   • Add window ownership details to event metadata
   • Enable filtering/grouping of modal-related ANRs

Impact

• Customers are disabling ANR detection due to noise
• Reduced reliability of actual freeze detection
• Decreased confidence in ANR reporting accuracy

Related Documentation

• Electron ANR Documentation

Notes

• Current workarounds using powerMonitor events exist but aren't officially supported/documented
  • not verified
• Re-enabling consideration depends on proper modal handling implementation

[smeubank]

https://www.electronjs.org/docs/latest/api/dialog#dialogshowsavedialogwindow-options

this is the electron API, i do not have anymore concrete examples of modals yet

[timfish]

You could create a helper function that disables ANR while the callback is being called. It would look something like this:

export async function disableAnrIntegration<T>(doWork: () => Promise<T>): Promise<T> {
  const integration = getClient()?.getIntegrationByName('Anr') as ReturnType<typeof nodeAnrIntegration> | undefined;

  try {
    integration?.stopWorker();
    return await doWork();
  } finally {
    integration?.startWorker();
  }
}

This would then be used like this:

const result = await disableAnrIntegration(() => dialog.showSaveDialog());

I'll get something like this added to the SDK so it's easier to use. We could automatically wrap everything in the Electron dialog module too.

[kpujjigit]

Hey @timfish I'm the original engineer at Sentry that proposed this feedback from a client. So it looks like the above draft would expose methods to manually pause/resume ANR detection? Would this also implement automatic detection of when system modal dialogs appear?

For further context, this feedback was provided to Sentry in response to how we handle the showSaveDialog modal. The application in-question presents a save dialogue box to open/save data, which invokes an intentional UI blockage, but the Electron SDK currently flags that as an app freeze. As a result, false positives are captured.

[timfish]

I've proposed adding this to the Node SDK (where the ANR feature originates) getsentry/sentry-javascript#14359

Once that is merged I can automatically wrap the Electron dialog code in this SDK which should fix the issue.