alerts and other blocking browser calls time out about nspluginwrapper HOT 4 OPEN

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.

from nspluginwrapper.

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.

from nspluginwrapper.

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.)

from nspluginwrapper.

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.

from nspluginwrapper.