alerts and other blocking browser calls time out

[davidben]

Some javascript calls block, notably alert(). This is a problem as the viewer does not know the browser's spawned a nested event loop and eventually times out. Probably we need to inform the viewer about this when appropriate or simply never time the viewer out. The latter may actually be a better approach (and more consistent with the plugin world), but we need to be careful not to leak the viewer when the wrapper crashes.

This is not a regression from anything I did, so I'm marking this for 1.6.0.

[davidben]

Though even if the viewer never times out, we may still need to communicate nested event loops. If the plugin expects its timers to still fired in a nested event loop, we'll need to be careful about things.

Really, blocking calls are just a terrible terrible idea.

[davidben]

This appears to also hit file upload dialogs. From a recent Google search:

flash-plugin and nspluginwrapper have an interesting conflict where
file selection boxes used for flash upload dialogs get closed randomly.

[davidben]

Alright, we do have to support a recursive GTK event loop. Disassembling flashplayer suggests it calls gtk_dialog_run when it creates a GtkFileSelector. (Wasn't that been deprecated for GtkFileChooser forever ago.) Alerts probably are a browser-side child event loop to deal with later. For plug-in-side ones, we probably want to detect them (hijack the poll func I guess) and then send the wrapper a message that we wish to recurse. And then the wrapper does a recursive event loop to follow suit and we continue with the sync event stuff. (Which will have to be rewritten AGAIN to use a poll func hack.)

[davidben]

One nuisance: what happens when the browser event loop isn't glib? Nested Xt event loops aren't worth supporting (if that's possible), but hopefully the world will move to NPN_PluginThreadAsyncCall. If we do (#17) before Flash does, things may be complicated... likely any "launch recursive event loop" RPC will need to have a fallback of some sort. Also such an RPC probably doesn't quite fit the method call pattern everywhere else as it'll integrate with sync/unsync.

On the other hand, browsers aren't going to stop using the glib event loop before Flash does, so #17 is probably uninteresting.