search

davidben / nspluginwrapper

A cross-platform NPAPI plugin viewer
http://nspluginwrapper.org
GNU General Public License v2.0
23 stars 10 forks source link

alerts and other blocking browser calls time out #24

Open davidben opened 13 years ago

davidben commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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.