davidben
Clean up Xt compatibility logic
Older plugins (in particular acroread) still assume the Xt main loop. While Chrome does not even attempt to support Xt, both Mozilla and nspluginwrapper have backwards-compatibility logic for it. Unfortunately, there does not exist a good way to hook Xt into a foreign main loop, so we're stuck with polling, and it's best to avoid this logic here possible. Our logic differs from Mozilla, so we should either match them or replace with something sane.
Mozilla initializes Xt and starts polling for plugins which are neither windowless or nor support XEmbed-based windowed mode on NPP_SetWindow. It also does this on NPN_GetValue when NPNVxDisplay is fetched with either a NULL plugin (acroread apparently needs this, though it may not need the event loop?) or a plugin which is not known to be either windowless or XEmbed. I believe you cannot hook into the Xt main loop without a Display so the latter code is probably all that is necessary. The former is probably because a GtkXtBin is needed.
nspluginwrapper initializes Xt unconditionally (creating an extra connection to the X server?) and, I believe incorrectly, uses that Display in random places, such as NPP_HandleEvent. It begins polling when any plugin that does not support XEmbed is created. (This is alright for Flash but may be wrong for a plugin which does not advertise XEmbed when it requires windowless mode.) It also attempts to detach the poll when all such plugin instances are gone. (Is this safe? What about a delayed response to NPP_Destroy?) We also have this horrible horrible logic to sniff the internal timer structure and look for the count of input sources. The code also doesn't actually work.
We should match Mozilla and get rid of the awful sniffing of Xt internal structures. Another possibility is to convince libXt to add new API (Eek! Though they did at XtAsprintf just this January.) that we can, when available, use to do this correctly. Another thought is to require thread-safe Xlib/Xt and call the internal locking hooks and _XtWaitForSomething on a dedicated thread.
Note to self: be careful about where you display x_display with GTK's display. Follow Mozilla's logic here: http://mxr.mozilla.org/mozilla-central/ident?i=xtdisplay&filter=
#33 is possibly caused by something related to Xt compatibility code. Mozilla's GtkXtBin is already checked in. Perhaps investigate using that in nspluginwrapper too, instead of some custom code. (Could even be fancy and bridge Xt whatever to the new XEmbed stuff. Because you clearly want to run acroread in Chrome.)