"unresponsive" event is incorrectly fired when calling synchronous version of dialog methods

[astoilkov]

• Electron version: 1.2.1
• Operating system: OS X 10.9.5
  1. Subscribe to the BrowserWindow "unresponsive" event (and add a debugger)
  2. Call the synchronous version of dialog. showOpenDialog() method
  3. Wait enough time and the debugger in the unresponsive event will be called

I understand why this happens. However, can something be done for this case? I hope you guys could fix it or maybe just provide an API for dialog.hasOpenDialog so this behavior could be fixed in our code.

[zcbenz]

How did you call the API? I think we have solved this before, we probably missed some cases.

[astoilkov]

Pasted the code we use below. Note that I have to wait 2-3 minutes before the unresponsive event is called. I also tested this behavior on newer operating system and the behavior was the same.

dialog.showOpenDialog({
  title: 'Open File',
  properties: ['openFile']
});

P.S. I could also test under Windows and Linux if you want.

[zcbenz]

Are you running the code in the main process? If so this would be quite surprising to me, the code is blocking the whole main process and there is no chance for unresponsive event to emit. A minimal app that can reproduce it would be very helpful here.

[astoilkov]

I call the dialog.showOpenDialog() method in the renderer process. Is this the problem?

[zcbenz]

Hmm I'm unable to reproduce by calling it in renderer process.

[astoilkov]

Ok. I will create a simple app that reproduces the issue.

[astoilkov]

Sorry for the delay but I will have to do it next week.

[astoilkov]

Hi,

I have created a simple app that replicates the issue. Steps to reproduce:

1. Open the app
2. Hit "s" character on the keyboard
3. The dialog will appear
4. Wait for 2-3 minutes
5. The unresponsive event is called and and a message box will appear

electron-dialog-unresponsive.zip

[zcbenz]

Hmm I can not reproduce with your app, it is probably because I'm using OS X 10.11.

[zcbenz]

Currently we only suppress unresponsive event when a dialog is attached to a window, which might be why it is happening for some systems. We should probably just suppress the unresponsive event for all windows as long as there is dialog showing.

[astoilkov]

I agree.

P.S. I have also tested the sample under OS X 10.11.5 and successfully replicated the problem. After I open the dialog I wait and don't do anything else (maybe this is also related).

[zcbenz]

Reopening since it reappears in v1.6.x.

[codebytere]

Left this up for 10 minutes on the latest master and could not reproduce, so i'm going to close this out! feel free to @ me for a reopen if it crops up again 😁