Chromium pumps the glib event loop on nested event loops. We don't
support the wrapper or the viewer recursively handling events on
themselves or each other anyway because of GSources can't recurse by
default (and it's insane). But with two event sources, we need
additional logic.
Bug #14.
This output is useful when trying to figure out what an NPN_Evalute is
doing. It would be nice not to do the strndup/free when not debugging,
but meh. We're already doing a string_of_NPVariant anyway.
Otherwise we still carry an implicit passive grab and the viewer cannot
upgrade to an active grab to show a context menu. This really only fixes
older Firefoxes as browsers which push plugins out-of-process themselves
(as they should) need to also include this fix. In theory this would
also fix Arora, but they have a QtWebKit bug where the event time is
bogus.
See browser bugs
http://code.google.com/p/chromium/issues/detail?id=40157http://bugzilla.mozilla.org/show_bug.cgi?id=544211Closes#16.
We may as well not pass NULL when we know what the value is. This
codepath doesn't run in Mozilla, but Mozilla uses a NULL instance to
trigger some backwards-compatibility Xt code.
We want these to run /immediately/. (Ideally right after the event loop
iteration returns.) So split it off into its own dedicated high-priority
source.
We still request a SYNC on new invokes, as before. However, we do not
unblock the SYNC with a SYNC_ACK (and correspondingly the SYNC_ACK with
a SYNC_END) until we return to the event loop. Originally, we unblock
when the current invoke is finished, so conflicts always alternate
method calls. This makes race conditions insane. Instead, we interleave
one event loop iteration's worth of invokes as a unit.
The end result should be that the wrapper never sees inconsistencies
(modulo main loop source priorities but those were already violated).
The viewer still may. However its inconsistencies are limited to the
first RPC'd NPAPI call in a single event loop iteration. We can get rid
of this by driving the viewer event loop ourselves and surrounding every
dispatch with a SYNC/SYNC_END pair (thus binding the two event loops
together), but this may be prohibitively expensive for dispatches that
don't call NPAPI.
Closes#14. The crash was caused by an NPN_Evaluate (triggering an
NPP_SetWindow browser-side) getting in between a
NPP_SetWindow/NPP_HandleEvent pair because windowless plugins on Linux
make no sense.
This is to work-around Chromium not doing the check itself. It's only
somewhat Chromium's fault as they're perfectly okay with segfaults
(separate plugin process) and a plugin shouldn't request
NPNVWindowNPObject on a NULL npp anyway. And, in fact, they don't. This
is a side effect of our RPC system not being able to distinguish a NULL
plugin instance from an invalid plugin instance.
This check should be removed when the fix in Chromium has trickled down
to the stable channel or when our RPC system becomes less awful.
GModule implements additional logic which we do not want. It will call
g_module_init_check and g_module_unload which is not part of the plugin
interface.
Also, we already explicitly look for -ldl whereas using gmodule wants
pkg-config gmodule-2.0 anyway.
Also move the code a little. This allows two nspluginwrapper plugins
with the same file name to be loaded at once in the same process. This
is not very important, except it appears Arora or QtWebKit call
NP_Initialize when probing plugins (instead of skipping to
NP_GetMIMEDescription and NP_GetValue like everyone else). They also
leave the plugin around evidently.
The result is that, if you have two versions of a wrapper Flash, the
second's will fail to bind the socket and then hang later on.
Two of those checks are local and one requires querying the browser.
Also, the latter will request NPNVxDisplay which triggers Xt
compatibility code in Mozilla. So lets try to make sure it never happens
on browsers newer than 2004 (i.e. that support npruntime).
Unfortunately they are incorrect. A Javascript object's properties may
change over time. In particular, code surrounding the video linked in
this unrelated bug report relied on this.
http://code.google.com/p/chromium/issues/detail?id=29907
Instead we set *_32 versions of all the variables to get the plugin
target build environment. When not building biarch, they are the same as
the wrapper build environment. (They should be renamed to _TARGET or
something or something.)
David Benjamin