I'm developing a mac plugin for WebKit, and on occasion it wants to use the keychain. This might possibly bring up the keychain's Deny/Allow/Always-Allow dialog. I've noticed that if that is left up there for more than about 45 seconds, our plugin process is killed. This is evidently the "hang-detection" timeout. WebKit suspends the hang-timeout, allowing modal dialogs to stay up essentially forever, using a swizzled runModalForDialog: function; but the keychain dialog is actually a separate process, called within any of a very large number of low-level calls so it would be impractical to swizzle or override them. Is there a way Safari/WebKit can detect that the plugin process is waiting for a keychain dialog and suspend the hang-timeout? Right now I have our plug-in creating a 1x1 modal dialog around calls that could possibly show a keychain, but frankly I don't know how many calls we have that could do it or where they are (I'm working with a large body of inherited code). It would be best to detect the situation rather than try to prevent it. I can create a plug-in that does this if needed, but will wait for comments about the feasibility of this.
This sounds closely related to bug 83829.
I don't think it's the same as bug 83829. In that one, our plugin is calling runModalWithDialog: which (in the webkit swizzling could) should trigger the hang-timeout suspension; I don't know why it does not. In this one, calls into the Mac OS X Security framework don't actually call runModalWithDialog. They communicate with a special-purpose process that deals with the keychain and shows that dialog (maybe for security reasons, since it's OS code I don't know). The plugin process is deep within the Security framework, on a mach wait.
Radar 11404931
*** Bug 98325 has been marked as a duplicate of this bug. ***
Created attachment 166992 [details] Patch
Committed r130347: <http://trac.webkit.org/changeset/130347>