Or at least make the lsb-build thing coherent. I think we're missing X11 headers right now.

Unfortunately, Linux does not appear to have a coherent way to correctly cross-compile things with system libraries. Existing patches just assume that the host architecture pkg-config flags and headers will work which is not necessarily true. Instead, we should require, say, pkg-config files for the viewer architecture and pass that along a command-line flag to configure until distributions can stop disagreeing on where the files live.

It would also be nice to switch to a better buildsystem or allow building multiple architectures' worth of viewers.

(In fact, reusing CFLAGS already doesn't work for glib. glibconfig.h is architecture-specific. lsb-build gets around this by defining all the macros with piles of architecture ifdefs.)

The viewer process is currently managed by the system package manager. Unfortunately, Linux package managers are somewhat blind to the requirements of the application, and viewer binaries get updated without regard for whether they're still used. This results in a window in which wrapped plugins are broken because no one ran the updater. This is very error-prone and, especially with Ubuntu diverting Flash for some alternatives thing, we get problems.

Instead, don't reference the system-installed viewer when building a wrapped plugin. Copy it elsewhere and garbage-collect viewers as all wrapped plugins get updated. The nspluginwrapper package then exists to install a template for creating wrapped plugins, rather than providing pieces of one.

This probably depends on #4.

As soon as I can be sure no existing patches are interesting (i.e., after fixing bug #4 with a serious rewrite), get rid of all the tabs in this source. Diffs are so hard to read when tabs are 4 spaces.

Using dlopen executes some code from it, and distributions run that tool as root. May as well avoid it and find some ELF parsing utilities to check for symbol existence.

From Chromium bug tracker. http://code.google.com/p/chromium/issues/detail?id=29907
Confirmed it still crashes us.

Chrome Version : <Copy from: 'about:version'> (Google Chrome Beta
4.0.249.30, Ubuntu Linux 9.10)
URLs (if applicable) : http://academicearth.org/lectures/genetic-engineering-and-society-1 (or a number of other videos on
AcademicEarth.org)
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
Firefox 3.x: OK
IE 7: OK
IE 8:

What steps will reproduce the problem?

1. Load the aforementioned URL and allow it to start playing the flash
   based video.
2. During video playback use the scroll wheel on the mouse to scroll the
   page up and down. Often the first movement will cause the plugin to crash,
   sometimes it takes a little more scrolling.
3. The flash video player will freeze and disappear.

What is the expected result?
The video should continue to play when scrolled.

What happens instead?
The flash video player freezes and disappears.

This really should be bug #1. This project is disturbing and really shouldn't exist. All remotely reasonable use cases will be handled when Chromium and Mozilla support 32-bit out-of-process plugins.

https://code.google.com/p/chromium/issues/detail?id=47400
https://bugzilla.mozilla.org/show_bug.cgi?id=588749

We probably should make them so, even though NPN_PluginThreadAsyncCall is the only thing that could be helped. In particular, the indent level wants to be thread-local storage and everything else should either also be thread-local or GOnce'd.

May be slightly more complicated if we don't want to assume the wrapper process has access to an initialized gthread. (Well, we could also assume pthreads.)

The current direct execution stuff is really a mess. Clean up the code a bit so that it may be used as a generic NPAPI tracing utility. The setting probably shouldn't be controlled by environment variable and instead baked into the wrapper. Also, don't require a viewer of the appropriate architecture as just a wrapper should be sufficient.

It's supposed to return the browser top-level window. Not clear exactly what it's used for (dialog parents? offsets?) or if this is actually a problem, but should investigate exactly what Chrome and Firefox do and see if it'd be better to mimic them. Flash does request sometimes.

We're almost there but still missing a few new additions. Though some of them may not even be implemented by anyone yet.

https://wiki.mozilla.org/NPAPI:AdvancedKeyHandling
https://wiki.mozilla.org/NPAPI:HTTPRedirectHandling
https://wiki.mozilla.org/NPAPI:ClearSiteData

A recent Ubuntu build contains the change

• Build with -O0 on armel; otherwise the wrapper fails to set up the connection to the viewer.

Unfortunately, no bug was filed with upstream, and no further information on this is visible. Pester the package maintainer at some point to figure out what this is about.

https://launchpad.net/ubuntu/oneiric/+source/nspluginwrapper/1.4.4-0ubuntu2

Not yet sure what's going on. Some log data:

*** NSPlugin Wrapper *** NPP_NewStream return: 0 [NPERR_NO_ERROR], stype=NP_NORMAL
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53f07b0 rect.top=0 rect.left=74 rect.bottom=186 rect.right=300
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect instance=0xe7c76e80 rect.top=0 rect.left=0 rect.bottom=90 rect.right=288
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53b87e0 rect.top=0 rect.left=0 rect.bottom=90 rect.right=288
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect instance=0xe7c76e80 rect.top=9 rect.left=472 rect.bottom=78 rect.right=702
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53b87e0 rect.top=9 rect.left=472 rect.bottom=78 rect.right=702
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect instance=0xe7c76e80 rect.top=0 rect.left=299 rect.bottom=66 rect.right=419
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53b87e0 rect.top=0 rect.left=299 rect.bottom=66 rect.right=419
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Wrapper *** NPP_WriteReady instance=0x53f0240

(npviewer.bin:26327): Gdk-WARNING **: GdkWindow 0x6e00540 unexpectedly destroyed
*** NSPlugin Viewer  *** NPN_InvalidateRect instance=0x8e251e8 rect.top=0 rect.left=74 rect.bottom=186 rect.right=300
*** NSPlugin Viewer  ***   handle_NPP_WriteReady
*** NSPlugin Viewer  ***   NPP_WriteReady instance=0x9253b68, stream=0x9a9aee0
*** NSPlugin Viewer  ***   NPP_WriteReady return: 268435455
*** NSPlugin Wrapper *** NPP_WriteReady return: 268435455
*** NSPlugin Wrapper *** NPP_Write instance=0x53f0240
*** NSPlugin Viewer  ***   handle_NPP_Write
*** NSPlugin Viewer  ***   NPP_Write instance=0x9253b68, stream=0x9a9aee0, offset=0, len=49, buf=0x9a46628
*** NSPlugin Viewer  ***   NPP_Write return: 49
*** NSPlugin Wrapper *** NPP_Write return: 49
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53f07b0 rect.top=0 rect.left=74 rect.bottom=186 rect.right=300
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect instance=0xe7c76e80 rect.top=0 rect.left=0 rect.bottom=90 rect.right=288
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53b87e0 rect.top=0 rect.left=0 rect.bottom=90 rect.right=288
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect instance=0xe7c76e80 rect.top=9 rect.left=472 rect.bottom=78 rect.right=702
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53b87e0 rect.top=9 rect.left=472 rect.bottom=78 rect.right=702
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect instance=0xe7c76e80 rect.top=0 rect.left=299 rect.bottom=66 rect.right=419
*** NSPlugin Wrapper *** handle_NPN_InvalidateRect
*** NSPlugin Wrapper *** NPN_InvalidateRect instance=0x53b87e0 rect.top=0 rect.left=299 rect.bottom=66 rect.right=419
*** NSPlugin Wrapper *** NPN_InvalidateRect done
*** NSPlugin Viewer  *** NPN_InvalidateRect done
*** NSPlugin Wrapper *** NPP_DestroyStream instance=0x53f0240

(npviewer.bin:26327): Gdk-WARNING **: GdkWindow 0x6e0053f unexpectedly destroyed

(npviewer.bin:26327): Gdk-WARNING **: GdkWindow 0x6e0053e unexpectedly destroyed

(npviewer.bin:26327): Gdk-WARNING **: GdkWindow 0x6e0053b unexpectedly destroyed
*** NSPlugin Viewer  *** handle_NPP_DestroyStream
*** NSPlugin Viewer  *** NPP_DestroyStream instance=0x9253b68, stream=0x9a9aee0, reason=NPRES_DONE
*** NSPlugin Viewer  *** NPP_DestroyStream return: 0 [NPERR_NO_ERROR]
*** NSPlugin Wrapper *** NPP_DestroyStream return: 0 [NPERR_NO_ERROR]
*** NSPlugin Wrapper *** NPP_URLNotify instance=0x53f0240, url='...', reason=NPRES_DONE, notifyData=0x8a
*** NSPlugin Viewer  *** g_NPP_Destroy_Now
*** NSPlugin Viewer  *** NPP_Destroy instance=0x944ec80
*** NSPlugin Viewer  ***   NPN_ReleaseObject 
*** NSPlugin Viewer  ***   NPN_ReleaseObject npobj=0x9364d34
*** NSPlugin Viewer  ***     handle_NPP_URLNotify
*** NSPlugin Viewer  ***     NPP_URLNotify instance=0x9253b68, url='...', reason=NPRES_DONE, notifyData=0x8a
*** NSPlugin Viewer  ***     NPP_URLNotify done
*** NSPlugin Wrapper *** NPP_URLNotify done
*** NSPlugin Wrapper *** handle_NPN_ReleaseObject
*** NSPlugin Wrapper *** NPN_ReleaseObject npobj=0x53f0980
*** NSPlugin Wrapper *** NPN_ReleaseObject done (refcount: 1)
*** NSPlugin Viewer  ***   NPN_ReleaseObject done (refcount: 1)
The program 'npviewer.bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 6108 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
*** NSPlugin Wrapper *** plugin_kill, connection 0x5346460
*** NSPlugin Wrapper *** plugin_exit
*** NSPlugin Wrapper *** Restart plugins viewer

The X errors may be much later because of async stuff. I don't think NPN_InvalidateRect causes a sync. May want an xtrace.

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.

This issue mostly exists to keep the milestone from auto-closing.

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.

Per http://developer.gnome.org/glib/2.31/glib-Deprecated-Thread-APIs.html#g-thread-init, the libs from gthread-2.0 should be used when g_thread_init is, patch below:

Description: Link with gthread-2.0 when using g_thread_init per GLIB API docs
Author: Micah Gersten [email protected]

Makefile | 5 +++--
configure | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)

Index: nspluginwrapper-1.4.4/configure

--- nspluginwrapper-1.4.4.orig/configure
+++ nspluginwrapper-1.4.4/configure
@@ -501,6 +501,7 @@
if $pkgconfig --exists glib-2.0; then
GLIB_CFLAGS=$pkgconfig --cflags glib-2.0
GLIB_LIBS=$pkgconfig --libs glib-2.0

• GTHREAD_LIBS=$pkgconfig --libs gthread-2.0
  GLIB_VERSION=$pkgconfig --modversion glib-2.0
  else
  echo "GLIB 2.0 environment not found"
  @@ -762,6 +763,7 @@
  echo "LDFLAGS=$LDFLAGS" >> $config_mak
  echo "GLIB_CFLAGS=$GLIB_CFLAGS" >> $config_mak
  echo "GLIB_LIBS=$GLIB_LIBS" >> $config_mak
  +echo "GTHREAD_LIBS=$GTHREAD_LIBS" >> $config_mak
  echo "GTK_CFLAGS=$GTK_CFLAGS" >> $config_mak
  echo "GTK_LIBS=$GTK_LIBS" >> $config_mak
  echo "CURL_CFLAGS=$CURL_CFLAGS" >> $config_mak

Index: nspluginwrapper-1.4.4/Makefile

--- nspluginwrapper-1.4.4.orig/Makefile
+++ nspluginwrapper-1.4.4/Makefile
@@ -89,6 +89,7 @@
GLIB_CFLAGS_32 = $(GLIB_CFLAGS)
GLIB_LIBS_32 = $(GLIB_LIBS)
GTK_CFLAGS_32 = $(GTK_CFLAGS)
+GTHREAD_LIBS_32 = $(GTHREAD_LIBS)
GTK_LIBS_32 = $(GTK_LIBS)
X_CFLAGS_32 = $(X_CFLAGS)
X_LIBS_32 = $(X_LIBS)
@@ -116,7 +117,7 @@
npviewer_CFLAGS += $(MOZILLA_CFLAGS)
npviewer_LDFLAGS = $(LDFLAGS_32)
npviewer_LDFLAGS += $(libpthread_LDFLAGS)
-npviewer_LIBS = $(GTK_LIBS_32) $(GLIB_LIBS_32) $(X_LIBS_32)
+npviewer_LIBS = $(GTK_LIBS_32) $(GTHREAD_LIBS_32) $(GLIB_LIBS_32) $(X_LIBS_32)
npviewer_LIBS += $(libdl_LIBS) $(libpthread_LIBS)
ifeq ($(TARGET_OS):$(TARGET_ARCH),linux:i386)
npviewer_MAPFILE = $(SRC_PATH)/src/npw-viewer.map
@@ -141,7 +142,7 @@
npplayer_CFLAGS += $(GTK_CFLAGS) $(GLIB_CFLAGS) $(MOZILLA_CFLAGS) $(CURL_CFLAGS) $(X_CFLAGS)
npplayer_LDFLAGS = $(LDFLAGS)
npplayer_LDFLAGS += $(libpthread_LDFLAGS)
-npplayer_LIBS = $(GTK_LIBS) $(GLIB_LIBS) $(CURL_LIBS) $(X_LIBS)
+npplayer_LIBS = $(GTK_LIBS) $(GTHREAD_LIBS) $(GLIB_LIBS) $(CURL_LIBS) $(X_LIBS)
npplayer_LIBS += $(libpthread_LIBS) $(libsocket_LIBS)

libnoxshm_LIBRARY = libnoxshm.so

Building nspluginwrapper in parallel using make -j5 or similar has a good chance to fail.

The reason lies here:

The simplest fix would be changing the prerequisites of the compiler target to this:
$(LSB_OBJ_DIR)/%.o: $(LSB_SRC_DIR)/%.c $(LSB_OBJ_DIR)
This will ensure that the target dir exists before any files are to be placed in it.

If you want me to, I can fork, commit that change, and post a pull request, but it's probably not worth the effort.

https://bugzilla.redhat.com/show_bug.cgi?id=691187

I believe the difference is that Firefox 4 now pushes nspluginwrapper out of process while it used to only push an unwrapped Flash out. Chromium appears unaffected even though it too has a three-process thing going on.

It's possible this is actually a QtWebKit bug (this bug has similar symptoms but is fixed https://bugs.webkit.org/show_bug.cgi?id=25053 ). The first Flash video loaded does not isplay and instead you get a white box where the video should bug. Should investigate whether this is our fault in the first place.

I believe --with-lib32 is no longer used anywhere. --with-lib64 is, but can probably be killed after figuring out where Solaris/BSD plug-in directories actually are. It's also used to determine LIBDIR so that wants to be replaced with something saner.

On linux, When attempting to wrap Oracle's 32-bit java plugin JRE version 1.6.0.24 (aka libnpjp2.so), nspluginwrapper reports a missing dependency (__gxx_personality_vo). The problem arises because the plugin expects the standard C++ runtime library to be loaded (stdlibc++.so). This problem could arise with other plugins as well.

It is worth noting that this patch will permit users to run the popular WebEx meeting client on 64-bit browsers. This client requires native 32-bit libraries on linux, and therefore will not run on a 64-bit JVM.

With the following patch, nspluginwrapper will create a wrapper for 32 bit Java without complaint. The JRE appears to execute correctly. My only discomfort with it is that I have hard-coded version 6 of the standard C++ library. It may be more appropriate to allow the most recent version to be selected.

--- npw-viewer.c    2011-06-30 23:18:57.000000000 -0400
+++ nspluginwrapper-1.4.4/src/npw-viewer.c  2012-03-11 14:09:35.104158681 -0400
@@ -5128,6 +5128,17 @@
    }
    handles[n_handles++] = handle;
    dlerror();
+#else
+   /* Install libstdc++ for java */
+   const char libstcpp[] = "libstdc++.so.6";
+   D(bug("  trying to open standard C++ runtime '%s'\n", libstcpp ));
+   if ((handle = dlopen(libstcpp, RTLD_LAZY|RTLD_GLOBAL)) == NULL) {
+     npw_printf("ERROR: %s\n", dlerror());
+     return 1;
+   }
+   handles[n_handles++] = handle;
+   dlerror();
+
 #endif
    D(bug("  %s\n", plugin_path));
    if ((handle = dlopen(plugin_path, RTLD_LAZY)) == NULL) {

https://bugzilla.mozilla.org/show_bug.cgi?id=603397

Looks like it's something to do with the plugin talking to X11 between two wrapper NPAPI calls.

Hi.

I haven't used nspluginwrapper in ages but due to the recent lack of a new 64bit flash version, Gentoo "forced" it upon me again. ;-) Unfortunately it did not work out of the box:

nspluginwrapper -v -i /opt/Adobe/flash-player32/plugin/libflashplayer.so
/usr/lib64/nspluginwrapper/i386/linux/npviewer.bin: relocation error: /usr/lib64/nspluginwrapper/i386/linux/npviewer.bin: symbol _Unwind_GetIPInfo, version GCC_3.0 not defined in file libgcc_s.so.1 with link time reference
/usr/lib64/nspluginwrapper/i386/linux/npviewer.bin: relocation error: /usr/lib64/nspluginwrapper/i386/linux/npviewer.bin: symbol _Unwind_GetIPInfo, version GCC_3.0 not defined in file libgcc_s.so.1 with link time reference
nspluginwrapper: no appropriate viewer found for /opt/Adobe/flash-player32/plugin/libflashplayer.so

_Unwind_GetIPInfo was added @ 4.2.0 and is thus 4.2.0. Changing libgcc_s.Version accordingly fixed the issue for me. Otherwise it was a simple no-go (see above).

Forgot to add: This is with a pretty much up2date "~amd64" Gentoo with gcc-4.4.5 (skipping 4.5.x series and waiting for another 4.6.x release to jump the boat -g-)

Not yet sure what's going on, and it's not completely reproducible. There does appear to be a race involved; the viewer is waiting for an SYNC_ACK to begin its event loop, but the wrapper had other work to do and never returns to its event loop for some reason.

FlashPlayer pluging keep crashing for one or two week.

I'm getting those messages in .xsession-error

Failed to open VDPAU backend libvdpau_r600.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type
Failed to open VDPAU backend libvdpau_r600.so: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type

Gdk-ERROR *: The program 'npviewer.bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 8415 error_code 8 request_code 140 minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
** NSPlugin Wrapper *** ERROR: NPP_HandleEvent() wait for reply: Connection closed
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2219):invoke_NPP_SetWindow: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2848):invoke_NPP_HandleEvent: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2655):invoke_NPP_WriteReady: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2705):invoke_NPP_Write: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2550):invoke_NPP_DestroyStream: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2434):invoke_NPP_URLNotify: assertion failed: (rpc_method_invoke_possible(plugin->connection))
*** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2848):invoke_NPP_HandleEvent: assertion failed: (rpc_method_invoke_possible(plugin->connection))

And kernel log is reporting:

[ 1293.179313] npviewer.bin[3470] trap int3 ip:3b4dc4d313 sp:7fff12aa9de0 error:0

This is pretty annoying. If the wrapper <-> viewer interface changes, Chrome seems to have a habit of crashing on wrapper update. Perhaps it tries to detect plugin changes or something crazy like that?

This happens even when the plugin process isn't running, which is particularly odd.

Or at least, I haven't been able to get it to work, so I've avoided updating its NPAPI thunks. It also has a free bug when passing --plugin.

% ./npplayer --plugin
*** glibc detected *** ./npplayer: free(): invalid pointer: 0x00000000009fdae8 ***
======= Backtrace: =========
/lib/libc.so.6(+0x774b6)[0x7fdf798634b6]
/lib/libc.so.6(cfree+0x73)[0x7fdf79869c83]
/lib/libglib-2.0.so.0(g_get_charset+0x99)[0x7fdf7a5ec119]
/lib/libglib-2.0.so.0(g_log_default_handler+0x1c6)[0x7fdf7a5c4736]
/lib/libglib-2.0.so.0(g_logv+0x1b9)[0x7fdf7a5c4b89]
/lib/libglib-2.0.so.0(g_log+0x83)[0x7fdf7a5c4fa3]
./npplayer[0x4075a8]
/lib/libglib-2.0.so.0(+0x40b1b)[0x7fdf7a5bab1b]
/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f2)[0x7fdf7a5ba342]
/lib/libglib-2.0.so.0(+0x442a8)[0x7fdf7a5be2a8]
/lib/libglib-2.0.so.0(g_main_loop_run+0x195)[0x7fdf7a5be7b5]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7fdf7b2943e7]
./npplayer[0x408855]
/lib/libc.so.6(__libc_start_main+0xfe)[0x7fdf7980ad8e]
./npplayer[0x404ec9]
======= Memory map: ========
00400000-00413000 r-xp 00000000 08:05 2371977                            /home/davidben/proj/nspluginwrapper/npplayer
00612000-00613000 r--p 00012000 08:05 2371977                            /home/davidben/proj/nspluginwrapper/npplayer
00613000-00614000 rw-p 00013000 08:05 2371977                            /home/davidben/proj/nspluginwrapper/npplayer
00614000-00615000 rw-p 00000000 00:00 0 
00913000-00a1b000 rw-p 00000000 00:00 0                                  [heap]
7fdf64000000-7fdf64021000 rw-p 00000000 00:00 0 
7fdf64021000-7fdf68000000 ---p 00000000 00:00 0 
7fdf6b728000-7fdf6b746000 r-xp 00000000 08:05 6187400                    /home/davidben/.mozilla/plugins/npwrapper.libflashplayer.so
7fdf6b746000-7fdf6b946000 ---p 0001e000 08:05 6187400                    /home/davidben/.mozilla/plugins/npwrapper.libflashplayer.so
7fdf6b946000-7fdf6b947000 r--p 0001e000 08:05 6187400                    /home/davidben/.mozilla/plugins/npwrapper.libflashplayer.so
7fdf6b947000-7fdf6b948000 rw-p 0001f000 08:05 6187400                    /home/davidben/.mozilla/plugins/npwrapper.libflashplayer.so
7fdf6b948000-7fdf6b966000 r-xp 00000000 08:05 6189490                    /home/davidben/.mozilla/plugins/npwrapper.libtest-plugin.so
7fdf6b966000-7fdf6bb66000 ---p 0001e000 08:05 6189490                    /home/davidben/.mozilla/plugins/npwrapper.libtest-plugin.so
7fdf6bb66000-7fdf6bb67000 r--p 0001e000 08:05 6189490                    /home/davidben/.mozilla/plugins/npwrapper.libtest-plugin.so
7fdf6bb67000-7fdf6bb68000 rw-p 0001f000 08:05 6189490                    /home/davidben/.mozilla/plugins/npwrapper.libtest-plugin.so
7fdf6bb68000-7fdf6bb83000 r-xp 00000000 08:05 1442598                    /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
7fdf6bb83000-7fdf6bd83000 ---p 0001b000 08:05 1442598                    /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
7fdf6bd83000-7fdf6bd84000 r--p 0001b000 08:05 1442598                    /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
7fdf6bd84000-7fdf6bd85000 rw-p 0001c000 08:05 1442598                    /var/lib/flashplugin-installer/npwrapper.libflashplayer.so
7fdf6bd85000-7fdf6bde2000 r-xp 00000000 08:05 7733344                    /opt/google/talkplugin/libnpgoogletalk64.so
7fdf6bde2000-7fdf6bfe2000 ---p 0005d000 08:05 7733344                    /opt/google/talkplugin/libnpgoogletalk64.so
7fdf6bfe2000-7fdf6bfe6000 rw-p 0005d000 08:05 7733344                    /opt/google/talkplugin/libnpgoogletalk64.so
7fdf6bfe6000-7fdf6c02a000 r-xp 00000000 08:05 3123                       /usr/lib/libQtXml.so.4.7.0
7fdf6c02a000-7fdf6c22a000 ---p 00044000 08:05 3123                       /usr/lib/libQtXml.so.4.7.0
7fdf6c22a000-7fdf6c22c000 r--p 00044000 08:05 3123                       /usr/lib/libQtXml.so.4.7.0
7fdf6c22c000-7fdf6c22d000 rw-p 00046000 08:05 3123                       /usr/lib/libQtXml.so.4.7.0
7fdf6c22d000-7fdf6c245000 r-xp 00000000 08:05 2730                       /usr/lib/libaudio.so.2.4
7fdf6c245000-7fdf6c444000 ---p 00018000 08:05 2730                       /usr/lib/libaudio.so.2.4
7fdf6c444000-7fdf6c445000 r--p 00017000 08:05 2730                       /usr/lib/libaudio.so.2.4
7fdf6c445000-7fdf6c446000 rw-p 00018000 08:05 2730                       /usr/lib/libaudio.so.2.4
7fdf6c446000-7fdf6c4bf000 r-xp 00000000 08:05 3221                       /usr/lib/libQtDBus.so.4.7.0
7fdf6c4bf000-7fdf6c6bf000 ---p 00079000 08:05 3221                       /usr/lib/libQtDBus.so.4.7.0
7fdf6c6bf000-7fdf6c6c0000 r--p 00079000 08:05 3221                       /usr/lib/libQtDBus.so.4.7.0
7fdf6c6c0000-7fdf6c6c1000 rw-p 0007a000 08:05 3221                       /usr/lib/libQtDBus.so.4.7.0
7fdf6c6c1000-7fdf6d160000 r-xp 00000000 08:05 709                        /usr/lib/libQtGui.so.4.7.0
7fdf6d160000-7fdf6d35f000 ---p 00a9f000 08:05 709                        /usr/lib/libQtGui.so.4.7.0
7fdf6d35f000-7fdf6d3a0000 r--p 00a9e000 08:05 709                        /usr/lib/libQtGui.so.4.7.0
7fdf6d3a0000-7fdf6d3a6000 rw-p 00adf000 08:05 709                        /usr/lib/libQtGui.so.4.7.0
7fdf6d3a6000-7fdf6d3a9000 rw-p 00000000 00:00 0 
7fdf6d3a9000-7fdf6d638000 r-xp 00000000 08:05 4023                       /usr/lib/libQtCore.so.4.7.0
7fdf6d638000-7fdf6d838000 ---p 0028f000 08:05 4023                       /usr/lib/libQtCore.so.4.7.0
7fdf6d838000-7fdf6d843000 r--p 0028f000 08:05 4023                       /usr/lib/libQtCore.so.4.7.0
7fdf6d843000-7fdf6d844000 rw-p 0029a000 08:05 4023                       /usr/lib/libQtCore.so.4.7.0
7fdf6d844000-7fdf6d845000 rw-p 00000000 00:00 0 
7fdf6d845000-7fdf6d856000 r-xp 00000000 08:05 133962                     /usr/lib/mozilla/plugins/skypebuttons.so
7fdf6d856000-7fdf6da55000 ---p 00011000 08:05 133962                     /usr/lib/mozilla/plugins/skypebuttons.so
7fdf6da55000-7fdf6da56000 r--p 00010000 08:05 133962                     /usr/lib/mozilla/plugins/skypebuttons.so
7fdf6da56000-7fdf6da57000 rw-p 00011000 08:05 133962                     /usr/lib/mozilla/plugins/skypebuttons.so
7fdf6da57000-7fdf6da58000 r-xp 00000000 08:05 133934                     /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
7fdf6da58000-7fdf6dc57000 ---p 00001000 08:05 133934                     /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.sozsh: abort      ./npplayer --plugin

Not really all too useful but we may be able to avoid making assumptions about the underlying main loop by using NPN_PluginThreadAsyncCall and pushing our event loop on a side thread.

It takes far too much boilerplate (about 100-odd lines per NPAPI function) to generate a single function's worth of thunks. This is also rather error-prone, though thankfully I haven't found any bugs short of wrong debug messages. It is probably worth generating these with C++ templates or something.

Maybe reuse Chromium's IPC system? Mozilla is already also using it.

The original logic is flimsy and distribution patches aren't that much better. Instead, replace with a policy-less C tool which management scripts (probably initially written by distributions) can call.

nspluginwrapper-1.4.0 install phase fails when used parallel make in projects like Gentoo. Solution provided in Gentoo bug system http://bugs.gentoo.org/show_bug.cgi?id=368665#c10.

There appears to be an issue with the Adobe Reader plugin. It seems that the plugin will exit when it is no longer in use. After this point, the browser instance will not be able to view PDFs anymore unless you go and kill off the nspluginwrapper instance.

A more concrete example (this is using Firefox 5 with Ubuntu Natty):

1. View a PDF in the browser.
2. Hit the back button.
3. Wait 30 seconds...acroread becomes a zombie.
4. Hit the forward button...you won't be able to view the PDF again.

At this point, if you kill -9 the nspluginwrapper instance and reload, you can view PDFs again.

Should nspluginwrapper perhaps be exiting itself when acroread does?

Sadly, some NPAPI hooks do not return an NPError which makes it difficult to return NPERR_INVALID_FUNCTABLE_ERROR. In addition, there are some hooks, such as NPP_URLRedirectNotify which trigger behavior based on whether the callback exists. In the case of NPP_URLRedirectNotify, the default behavior is obvious: call NPN_URLRedirectResponse(instance, notifyData, true). Nonetheless, the context switch is unnecessary and we should avoid advertising hooks to the browser which the plugin does not support at all.

Hi there,

I try to compile nspluginwrapper-1.4.4 but always get this bug , which I am struggle to understand:

gcc -std=c99 -m32 -Llsb-build-i386 -Wl,--export-dynamic -Wl,--version-script,/usr/src/nspluginwrapper-1.4.4/src/npw-viewer.map -o npviewer.bin npviewer-npw-viewer.o npviewer-npw-common.o npviewer-npw-malloc.o npviewer-npw-rpc.o npviewer-rpc.o npviewer-debug.o npviewer-utils.o npviewer-npruntime.o npviewer-cxxabi-compat.o -lgtk-x11-2.0 -lgdk-x11-2.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lX11 -lXt -ldl -lpthread -lsupc++
gcc -std=c99 -o libnoxshm-libnoxshm.o -c /usr/src/nspluginwrapper-1.4.4/src/libnoxshm.c -I. -I/usr/src/nspluginwrapper-1.4.4 -m32 -O2 -g -mtune=generic -I/usr/src/nspluginwrapper-1.4.4/lsb-build/headers -fPIC
gcc -std=c99 -shared -m32 -Llsb-build-i386 -o libnoxshm.so libnoxshm-libnoxshm.o -Wl,-soname,libnoxshm.so
lsb-build-i386/libc_nonshared.a(libc_nonshared.o): In function __libc_csu_fini': /usr/src/nspluginwrapper-1.4.4/lsb-build/stub_libs/libc_nonshared.c:94: undefined reference to__fini_array_end'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: lsb-build-i386/libc_nonshared.a(libc_nonshared.o): relocation R_386_GOTOFF against undefined hidden symbol `__fini_array_end' can not be used when making a shared object
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make: *** [libnoxshm.so] Error 1
rm lsb-build-i386/libXext.o lsb-build-i386/libgcc_s.o lsb-build-i386/libc_main.o lsb-build-i386/libpthread.o lsb-build-i386/libdl.o lsb-build-i386/libgobject-2.0.o lsb-build-i386/libgdk-x11-2.0.o lsb-build-i386/libgtk-x11-2.0.o lsb-build-i386/libgthread-2.0.o lsb-build-i386/libX11.o lsb-build-i386/libXt.o lsb-build-i386/libglib-2.0.o lsb-build-i386/libc_nonshared.o

I use the vanilla tar file (I just disabled the stack protector with -fno-stack-protector)
I understand this has to do with the linker and shared libraries.

Any idea?

The sound still works, but the video often stops. It seems to do so much less often than before as of some change or another, but it still occurs. In particular, pressing volume up seems to always stop it. (What? Maybe the notification thing?)

Currently the RPC layer prints an error and then returns NULL. Instead, it should signal this error and then let the caller return NPERR_INVALID_INSTANCE_ERROR. While the browsers probably should check for NULL themselves, Chromium doesn't in NPN_GetValue (fix has been committed, but it may not trickle down to stable for a bit), and it's poor of us to pass NULL to the browser unless the plugin specifically requested it.

Unfortunately, this may be difficult to handle on our end without #9.

I'm using nspluginwrapper 1.4.4 and for example if I'm executing "nspluginwrapper -vu ./npwrapper.libflashplayer.so" I'm getting the error "invalid option -vu" while executing "nspluginwrapper -v -u ./npwrapper.libflashplayer.so" does work. Maybe nspluginwrapper can also support accepting options like in the first case.

I'm using nspluginwrapper 1.4.2. Running Flash applications work fine. However, if I put a window with a white background over the window with the flash plug-in, that I can see "through" the window, and I can "see" the flash application through the white window.

This remembers me of the "good old times", when a video overlay was basically a rectangle filled with a particular color. And every pixel on the screen with the right color was replaced that has the right color was replaced with the overlay content. Well, it seems nspluginwrapper is using an overlay. However, with a particularly bad color (white).

I remember, that sometimes it affects windows with black background (like my terminal window).

I'm using nvidia's binary driver.

Older generations of browsers would run plugins in-process, so the wrapper would try to avoid crashing when the viewer did, as a nasty hack. Nowadays this logic is unnecessary as modern browsers run plugins in separate processes. In fact the logic is harmful as it gets in the way of the browser's own crash logic and instead just returns an error to all queries.

We should drop this logic and just crash the browser. Unfortunately, there still exist random niche browsers which run plugins in-process and they still need the hack. We can sniff the user agent, but It may be worth talking to the NPAPI development list and seeing if we can get a safe "I've crashed, kill me now" hook for modern browsers to implement.

Stub objects on one side often don't get told when they get deallocated. Also it involves this hacky delayed calls mechanism.

Closing this when npobject-bridge is merged.

/usr/include/glib-2.0/glib/gthread.h:28:2: error: #error "Only <glib.h> can be included directly."

This can be fixed trivially with:

Index: nspluginwrapper-1.4.4/src/npw-player.c
===================================================================
--- nspluginwrapper-1.4.4/src/npw-player.c
+++ nspluginwrapper-1.4.4/src/npw-player.c      2011-12-16 05:22:25.672747496 +0200
@@ -24,8 +24,6 @@
 #include <dlfcn.h>
 #include <unistd.h>
 #include <glib.h>
-#include <glib/gstdio.h>
-#include <glib/gthread.h>
 #include <gtk/gtk.h>
 #include <gdk/gdkx.h>
 #include <gdk/gdkkeysyms.h>

I'm using nspluginwrapper 1.4.4 and it seems nspluginwrapper can't find relative files without a leading ./. Here is what happens:

sworddragon@ubuntu:~/.mozilla/plugins$ nspluginwrapper -v -u npwrapper.libflashplayer.so
nspluginwrapper: npwrapper.libflashplayer.so is not a valid nspluginwrapper plugin

But using a leading ./ results in this:

sworddragon@ubuntu:~/.mozilla/plugins$ nspluginwrapper -v -u ./npwrapper.libflashplayer.so
Update plugin ./npwrapper.libflashplayer.so
NPAPI plugin /home/sworddragon/.mozilla/plugins/libflashplayer.so was modified, reinstalling plugin
Install plugin /home/sworddragon/.mozilla/plugins/libflashplayer.so
into /home/sworddragon/.mozilla/plugins/npwrapper.libflashplayer.so

Both the old Xt-based and new XEmbed-based windowed modes involve creating viewer-side stubs for the plugin to attach itself to. At least for the XEmbed one, we should be able to do away with it and embed into the parent directly. Chrome manages this, and everything is now completely synchronous, so there shouldn't be issues with the browser killing the parent early.

This issue mostly exists to keep the milestone from auto-closing.

Unit tests are good things. We should have them.

I do not know if this is Mageia specific or upstream.
I posted a bug at Magiea bug tracker
And post it here too for advice, and will link to this from Mageia.
https://bugs.mageia.org/show_bug.cgi?id=9053 below:

----------------------8<----------------
Package: nspluginwrapper

Description of problem:
Suddenly my security plugin for Firefox did not work anymore.
I tracked it to an automatic update of flash browser plugin;
Updating flash-player-plugin makes libplugins.so loose the wrapper!

nspluginwrapper -l

listed nothing, so i "rewrapped" it again like when i installed it:

nspluginwrapper -i /usr/local/lib/personal/libplugins.so

And it is working again.
The plugin is for BankID, see my HOWTO referenced below

I posted the problem in forum
https://forums.mageia.org/en/viewtopic.php?f=7&t=4386
and doktor5000 replied: Probably a bug with nspluginwrapper, or specifically
with one of the filetriggers /var/lib/rpm/filetriggers/nspluginwrapper.*

Version-Release number: 1.4.4-1.mga2

How reproducible:
Confirmed on another computer with same setup.

Steps to Reproduce:

1. Have elder version flash-player-plugin installed
2. Run nspluginwrapper -i /usr/local/lib/personal/libplugins.so
   I have only tried that plugin, see my HOWTO on Nexus BankID
   https://forums.mageia.org/en/viewtopic.php?f=41&t=4384
   Verify it installed: run nspluginwrapper -l
3. update flash-player-plugin
   I now have version: 11.2.202.262-1.mga2.nonfree

4. See the plugin is gone by using: nspluginwrapper -l

(EDITed to avoid bad autoformatting)

When calling npconfig -v -i on a native plugin, nothing will happen. It would be better to report it has decided not to wrap the plugin because it's native.

While investigating issue 33, I found that when 'nspluginwrapper -a -v -u' is run, it removes the symbolic links to the Adobe Reader plugin, leaving the plugin effectively disabled. I am thinking that the correct behavior might be that nspluginwrapper should probably act on the linked file, not the link itself.

I am using the webkit-based PhantomJS (https://github.com/ariya/phantomjs) to make screenshots of web pages. Flash content is a bit problematic though, several pages (example: http://www.adobe.com/software/flash/about/) hang the rendering process. I have tried nspluginwrapper 1.2.2 (default Ubuntu) which spawns the following errors:

*** NSPlugin Viewer  *** WARNING: unhandled variable 18 (<unknown variable>) in NPN_GetValue()
(process:30321): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.28.6/./gobject/gtype.c:2712: You forgot to call g_type_init()
(process:30321): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(process:30321): Gdk-CRITICAL **: IA__gdk_x11_display_get_xdisplay: assertion `GDK_IS_DISPLAY (display)' failed
*** NSPlugin Viewer  *** WARNING: unhandled variable 18 (<unknown variable>) in NPN_GetValue()

Upgrading to nspluginwrapper 1.4.4 (from source) spawns similar errors:

(process:29911): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.28.6/./gobject/gtype.c:2712: You forgot to call g_type_init()
(process:29911): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(process:29911): Gdk-CRITICAL **: IA__gdk_x11_display_get_xdisplay: assertion `GDK_IS_DISPLAY (display)' failed
*** NSPlugin Viewer  *** ERROR: rpc_end_sync called when not in sync!

Any thoughts? If I can help with a gdb stack trace or more verbose debug messages, let me know.

This appears to be both a Chromium and nspluginwrapper bug. A portion appears to be a WebKit problem, but I believe there is also a nspluginwrapper bug in here.

http://code.google.com/p/chromium/issues/detail?id=40157

Seems to be a /very/ tight race condition somewhere. Running in Firefox 3.6 with nspluginwrapper causes a hang always. A few print statements makes it happen less often. Timestamps seem okay, so maybe something else is going on? Hard to test in Chromium because they filter out right clicks, and there are apparently other bugs in the way there anyway. Firefox 4.0 without nspluginwrapper works fine.