From gb.public at free.fr Mon Dec 1 08:52:08 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Mon, 1 Dec 2008 09:52:08 +0100 (CET) Subject: [ANN] nspluginwrapper 1.1.8 (SVN) In-Reply-To: <25390081.2039461228121176420.JavaMail.root@spooler5-g27.priv.proxad.net> Message-ID: <25443544.2040251228121528208.JavaMail.root@spooler5-g27.priv.proxad.net> Hi, SVN trunk represents nspluginwrapper 1.1.8 with the following changes: * Delay NPN_ReleaseObject() if there is incoming RPC * Improve plugins restart machinery (Martin Stransky) * Close npviewer.bin sockets on exec() * Close all open files on fork() (initial patch by Dan Walsh) * Make `which` failures silent for soundwrappers (Stanislav Brabec) Issues holding nspluginwrapper 1.2.0 release. * Fix invalid RPC after NPP_Destroy() This one is simple to fix, though a I foresee a large patch. * Fix XEMBED regressions, e.g. key events are lost. It seems Firefox 3.1b2 works though not 3.0-branch. Well, huh, I probably will be more inspired for this one in the next days. ;-) Regards, Gwenole. From stransky at redhat.com Mon Dec 1 15:30:43 2008 From: stransky at redhat.com (Martin Stransky) Date: Mon, 01 Dec 2008 16:30:43 +0100 Subject: Upstreaming Fedora's patches? In-Reply-To: References: <491CD36D.9050304@redhat.com> Message-ID: <49340323.7080209@redhat.com> Gwenole Beauchesne wrote: > Hi, > > Le 14 nov. 08 ? 02:25, Warren Togami a ?crit : > Concerning the PID check, is there a real situation that needed that > patch? I mean, what plugin fork()'es the browser and does not exec() > something afterwards? I think I did the patch because of flash plugin, I got some browser crash. But from my current view the patch looks quite useless...anyway if you use USE_PID_CHECK now the check function returns false so it always fails ;-) > That check is currently enabled by default, though it can be disabled at > compile time with USE_PID_CHECK = 0. Note that the npruntime bridge is > not patched yet. Cool, I,ve just updated fedora rawhide package to 1.1.8 and removed all fedora specific patches (except the event one). btw. What do you mean with "that the npruntime bridge is not patched yet"? It looks complete to me... thanks, ma. From wtogami at redhat.com Mon Dec 1 22:31:26 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 01 Dec 2008 17:31:26 -0500 Subject: [ANN] nspluginwrapper 1.1.8 (SVN) In-Reply-To: <25443544.2040251228121528208.JavaMail.root@spooler5-g27.priv.proxad.net> References: <25443544.2040251228121528208.JavaMail.root@spooler5-g27.priv.proxad.net> Message-ID: <493465BE.2030907@redhat.com> Gwenole Beauchesne wrote: > Hi, > > SVN trunk represents nspluginwrapper 1.1.8 with the following changes: > > * Delay NPN_ReleaseObject() if there is incoming RPC > * Improve plugins restart machinery (Martin Stransky) > * Close npviewer.bin sockets on exec() > * Close all open files on fork() (initial patch by Dan Walsh) > * Make `which` failures silent for soundwrappers (Stanislav Brabec) > > Issues holding nspluginwrapper 1.2.0 release. > > * Fix invalid RPC after NPP_Destroy() > This one is simple to fix, though a I foresee a large patch. > > * Fix XEMBED regressions, e.g. key events are lost. It seems Firefox 3.1b2 works though not 3.0-branch. > Well, huh, I probably will be more inspired for this one in the next days. ;-) > http://koji.fedoraproject.org/scratch/wtogami/task_967679/ Test build of 1.1.8 for Fedora 10. Seems to be working great. We should push an official update of nspluginwrapper for Fedora 9 and 10 soon. This is already a big improvement over the 1.1.4 we currently ship. Should we ship 1.1.8 or wait for 1.2.0? Warren Togami wtogami at redhat.com From gb.public at free.fr Tue Dec 2 22:47:43 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Tue, 2 Dec 2008 23:47:43 +0100 Subject: Upstreaming Fedora's patches? In-Reply-To: <49340323.7080209@redhat.com> References: <491CD36D.9050304@redhat.com> <49340323.7080209@redhat.com> Message-ID: <00DFB59F-362E-48E4-BB6B-A86343ED5ABE@free.fr> Hi, Le 1 d?c. 08 ? 16:30, Martin Stransky a ?crit : >> Concerning the PID check, is there a real situation that needed >> that patch? I mean, what plugin fork()'es the browser and does not >> exec() something afterwards? [...] > But from my current view the patch looks quite useless...anyway if > you use USE_PID_CHECK now the check function returns false so it > always fails ;-) Yes, the patch would be only useful for a plugin that fork() without exec()'ing. I have disabled the check in SVN trunk and also fixed the USE_PID_CHECK == 0 case at the same time. >> That check is currently enabled by default, though it can be >> disabled at compile time with USE_PID_CHECK = 0. Note that the >> npruntime bridge is not patched yet. > > Cool, I,ve just updated fedora rawhide package to 1.1.8 and removed > all fedora specific patches (except the event one). > > btw. What do you mean with "that the npruntime bridge is not patched > yet"? It looks complete to me... Well, this is because I slept between those two events and the missing part was only committed the day after. ;-) So, pid_check() support is indeed complete. Regards, Gwenole. From gb.public at free.fr Tue Dec 2 23:16:36 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Wed, 3 Dec 2008 00:16:36 +0100 Subject: [ANN] nspluginwrapper 1.1.8 (SVN) In-Reply-To: <493465BE.2030907@redhat.com> References: <25443544.2040251228121528208.JavaMail.root@spooler5-g27.priv.proxad.net> <493465BE.2030907@redhat.com> Message-ID: Hi, Le 1 d?c. 08 ? 23:31, Warren Togami a ?crit : > Test build of 1.1.8 for Fedora 10. Seems to be working great. We > should push an official update of nspluginwrapper for Fedora 9 and > 10 soon. This is already a big improvement over the 1.1.4 we > currently ship. Well, 1.1.8 has a crasher that could happen under certain circumstances. This is very unpleasant to get "grey boxes", generic term from users to mean something crapped out from nspluginwrapper. That covers multiple issues, most were already fixed in past releases. I will post a fix to the remaining one in another mail. > Should we ship 1.1.8 or wait for 1.2.0? 1.1.8 + the patch to "Fix invalid RPC after NPP_Destroy()" should be fine with more testing. 1.2.0 will be out only if I manage to fix the XEMBED regressions. And a formal release can't happen before one week, at least (testing on several platforms). The XEMBED regressions (that existed in 1.1.4 too) are embarassing because sometimes, and with some browsers, events are not propagated to the plugin. I will test something tomorrow. Thanks, Gwenole. From gb.public at free.fr Tue Dec 2 23:38:48 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Wed, 3 Dec 2008 00:38:48 +0100 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() Message-ID: Hi, Sorry, the patch is large but it was necessary to fix the following scenario: Browser: NPP_Destroy() -> rpc_method_invoke() Viewer: NPN_InvalidateRect() -> rpc_method_invoke() -> rpc_dispatch() pending messages -> handle_NPP_Destroy() -> PluginInstance is killed -> get back and do send RPC for NPN_InvalidateRect() Browser: -> got NPP_Destroy() reply -> handle_NPN_InvalidateRect() but NPP instance is invalid This scenario is non-deterministic, i.e. there is no 100% way to reproduce it. However, here is the strategy I took and all commits were reviewed carefully. So, it should be fine, incrementally. 1) reference counting PluginInstance makes it possible to keep them longer as needed 2) on NPP_Destroy() in the viewer, relations between NPP and PluginInstance are cancelled, thus any PluginInstance passed to RPC after an NPP_Destroy() will arrive as NULL into the other side. And this case is handled by NPN_*() functions. Regards, Gwenole. -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-fix-invalid-RPC-after-NPP_Destroy.patch.gz Type: application/x-gzip Size: 11306 bytes Desc: not available URL: -------------- next part -------------- From gb.public at free.fr Tue Dec 2 23:54:45 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Wed, 3 Dec 2008 00:54:45 +0100 Subject: About the NPW_DIRECT_EXEC feature Message-ID: Hi, I forgot to mention the following feature in 1.1.8 release notes: * Make it possible to execute wrapped native plugins directly, without npviewer.bin In other words, NPW_DIRECT_EXEC=1 firefox will make the plugins work as if they were not wrapped. This is mostly interesting for debugging and avoids un-wrapping and updating the symbolic links to the native plugins. Note however this mode is not 100% identical to a direct use of the plugin. The only differences are NPAPI version exposed to the plugin (0.17) and the following unimplemented functions: NPN_ReloadPlugins(), NPN_InvalidateRegion(), NPN_ForceRedraw(), NPP_SetValue(). Those differences are wanted (to check at the same features levels as npviewer.bin). It's fairly easy to suppress those differences. i.e. copy the missing NPNetscapeFuncs and npapi_version from the original NPNetscapeFuncs table (in NP_Initialize()). Regards, Gwenole. From wtogami at redhat.com Wed Dec 3 03:53:04 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 02 Dec 2008 22:53:04 -0500 Subject: [PATCH] Re: Leaked file descriptors from browser to npviewer.bin In-Reply-To: <19336972.1973181228037830746.JavaMail.root@spooler5-g27.priv.proxad.net> References: <19336972.1973181228037830746.JavaMail.root@spooler5-g27.priv.proxad.net> Message-ID: <493602A0.5050307@redhat.com> Gwenole Beauchesne wrote: > Hi, > > ----- "Warren Togami" a ?crit : > >> Are all of these file descriptors from npviewer.bin and Flash? It >> appears that some are leaked from the fork() from firefox. According >> to >> dwalsh, SELinux automatically closes some leaked file descriptors that >> >> are not allowed after the transition, but others remain? > > I have committed the following patch. > 1) Close all open files. I used different strategies to determine OPEN_MAX. call to getrlimit() could be removed on contemporary systems though. > 2) Add SOCK_CLOEXEC to socket(). I have not tested this one yet (e.g. mplayerplug-in) > Looking at the /proc//fd/ it appears things are cleaner now. There appear to be no drawbacks of this? I wonder if some of the SELinux denials reported were the result of leaked file descriptors. Warren From wtogami at redhat.com Wed Dec 3 04:02:35 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 02 Dec 2008 23:02:35 -0500 Subject: Thank You Gwenole In-Reply-To: References: Message-ID: <493604DB.2090702@redhat.com> Gwenole, I just want to express my appreciation for your rapid fixes and good work. I especially am amazed by your rapid responses to user reports and patches for testing on the list. It is clear to me that this is the ideal approach for the future of the browser. I hope that others see the benefits of process isolation as nspluginwrapper becomes more stable and complete. I hope that others can join me in appreciation of Gwenole's work. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Dec 3 04:45:48 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 02 Dec 2008 23:45:48 -0500 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: References: Message-ID: <49360EFC.2030307@redhat.com> http://kojipkgs.fedoraproject.org/packages/nspluginwrapper/1.1.8/ I have built 1.1.8 plus this patch for F10 and F11. I see a case while playing Youtube videos, sometimes the plugin turns into a grey box. npviewer.bin is no longer running. Reloading the page once fails to recover. Reloading the second time makes it work again. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Dec 3 19:15:29 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 03 Dec 2008 14:15:29 -0500 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: <49360EFC.2030307@redhat.com> References: <49360EFC.2030307@redhat.com> Message-ID: <4936DAD1.5010503@redhat.com> Warren Togami wrote: > http://kojipkgs.fedoraproject.org/packages/nspluginwrapper/1.1.8/ > I have built 1.1.8 plus this patch for F10 and F11. > > I see a case while playing Youtube videos, sometimes the plugin turns > into a grey box. npviewer.bin is no longer running. Reloading the page > once fails to recover. Reloading the second time makes it work again. > Playing Youtube fails randomly in the middle of a video. (gdb) bt full #0 __pthread_mutex_lock (mutex=0x7f601426f068) at pthread_mutex_lock.c:51 oldval = retval = __PRETTY_FUNCTION__ = "__pthread_mutex_lock" #1 0x00007f60154d953a in ?? () from /usr/lib64/mozilla/plugins/libflashplayer.so No symbol table info available. #2 0x00007f601543aa80 in ?? () from /usr/lib64/mozilla/plugins/libflashplayer.so No symbol table info available. #3 0x00007f60152ef18e in ?? () from /usr/lib64/mozilla/plugins/libflashplayer.so No symbol table info available. #4 0x0000003cc4436930 in __cxa_finalize (d=0x7f6015d4a6a0) at cxa_finalize.c:56 check = 3 cxafn = (void (*)(void *, int)) 0x1e49ac0 cxaarg = (void *) 0x7f601426f068 f = (struct exit_function *) 0x3cc476d330 funcs = (struct exit_function_list *) 0x3cc476d2e0 #5 0x00007f60152d7303 in NSS_CMSMessage_GetContentInfo () at cmsmessage.c:173 No symbol table info available. #6 0x00007fff21e92110 in ?? () No symbol table info available. #7 0x00007f60159b7531 in NSS_CMSMessage_GetContentInfo () at cmsmessage.c:173 No symbol table info available. #8 0x000000000000005f in ?? () No symbol table info available. #9 0x0000003cc4014954 in _dl_close_worker (map=) at dl-close.c:271 imap = (struct link_map *) 0x1e435e0 i = 32608 nsid = 140050650993978 ns = (struct link_namespaces *) 0x7f6015d4a6a0 any_tls = false nloaded = 95 idx = done_index = unload_any = false scope_mem_left = 48 unload_global = 366401408 first_loaded = 32608 r = (struct r_debug *) 0x3cc476d330 tls_free_start = 260994159344 tls_free_end = 140050659845792 dl_close_state = pending __PRETTY_FUNCTION__ = "_dl_close_worker" Backtrace stopped: previous frame inner to this frame (corrupt stack?) From gb.public at free.fr Wed Dec 3 23:20:58 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Thu, 4 Dec 2008 00:20:58 +0100 Subject: [PATCH] Send NPN_InvalidateRect() on idle Message-ID: Hi, The most correct fix is scheduled for nspluginwrapper2 with another change to the RPC protocol and implementation. However, the patch in attachment will do the job in the mean time. Various optimizations are possible, I mentioned a few in comments, but it's out of nspluginwrapper 1.2.0 scope. Regards, Gwenole. -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-NPN_InvalidateRect-on-idle.patch Type: application/octet-stream Size: 4559 bytes Desc: not available URL: -------------- next part -------------- From wtogami at redhat.com Thu Dec 4 01:48:47 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 03 Dec 2008 20:48:47 -0500 Subject: [PATCH] Send NPN_InvalidateRect() on idle In-Reply-To: References: Message-ID: <493736FF.5000405@redhat.com> Gwenole Beauchesne wrote: > Hi, > > The most correct fix is scheduled for nspluginwrapper2 with another > change to the RPC protocol and implementation. However, the patch in > attachment will do the job in the mean time. Various optimizations are > possible, I mentioned a few in comments, but it's out of nspluginwrapper > 1.2.0 scope. > This patch shouldn't affect stability? Only performance? Warren From gb.public at free.fr Wed Dec 3 23:26:25 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Thu, 4 Dec 2008 00:26:25 +0100 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: <49360EFC.2030307@redhat.com> References: <49360EFC.2030307@redhat.com> Message-ID: Hi, Le 3 d?c. 08 ? 05:45, Warren Togami a ?crit : > I see a case while playing Youtube videos, sometimes the plugin > turns into a grey box. npviewer.bin is no longer running. > Reloading the page once fails to recover. Reloading the second time > makes it work again. OK, I could reproduce the bug. Thanks. I think the patch to emit NPN_InvalidateRect() on idle (in another mail) should work for you too. Just to be sure, you had the 64-bit Flash plugin and enabled windowless mode, right? Regards, Gwenole. From wtogami at redhat.com Thu Dec 4 05:16:19 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 04 Dec 2008 00:16:19 -0500 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: References: <49360EFC.2030307@redhat.com> Message-ID: <493767A3.70709@redhat.com> Gwenole Beauchesne wrote: > Hi, > > Le 3 d?c. 08 ? 05:45, Warren Togami a ?crit : > >> I see a case while playing Youtube videos, sometimes the plugin turns >> into a grey box. npviewer.bin is no longer running. Reloading the >> page once fails to recover. Reloading the second time makes it work >> again. > > OK, I could reproduce the bug. Thanks. I think the patch to emit > NPN_InvalidateRect() on idle (in another mail) should work for you too. NPN_InvalidateRect() will help stability? If so, nspluginwrapper-2 might be a long wait. > > Just to be sure, you had the 64-bit Flash plugin and enabled windowless > mode, right? > firefox-3.0.4-1.fc10.x86_64 flash-plugin-10.0.20.7-0.x86_64 nspluginwrapper-1.1.8-2.fc10.x86_64 which includes Fix invalid RPC after NPP_Destroy() [root at newcaprica tmp]# cat /etc/adobe/mms.cfg WindowlessDisable=true I also turned off windowless because I figure fewer people are testing it this way. I'll try it without it disabled now. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Dec 4 05:34:36 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 04 Dec 2008 00:34:36 -0500 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: References: <49360EFC.2030307@redhat.com> Message-ID: <49376BEC.9050804@redhat.com> Gwenole Beauchesne wrote: > Hi, > > Le 3 d?c. 08 ? 05:45, Warren Togami a ?crit : > >> I see a case while playing Youtube videos, sometimes the plugin turns >> into a grey box. npviewer.bin is no longer running. Reloading the >> page once fails to recover. Reloading the second time makes it work >> again. > > OK, I could reproduce the bug. Thanks. I think the patch to emit > NPN_InvalidateRect() on idle (in another mail) should work for you too. BTW, what distro do you use with nspluginwrapper development and testing? What versions of kernel, glibc, pulseaudio are you using? SMP or hyperthreading? Is your libcurl linked to openssl or nss? All this info might help me narrow down problems... Warren From gb.public at free.fr Thu Dec 4 05:51:44 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Thu, 4 Dec 2008 06:51:44 +0100 Subject: [PATCH] Send NPN_InvalidateRect() on idle In-Reply-To: <493736FF.5000405@redhat.com> References: <493736FF.5000405@redhat.com> Message-ID: <17A52342-1529-4810-AFC0-A7E934D9B4D5@free.fr> Hi, Le 4 d?c. 08 ? 02:48, Warren Togami a ?crit : > Gwenole Beauchesne wrote: >> Hi, >> The most correct fix is scheduled for nspluginwrapper2 with another >> change to the RPC protocol and implementation. However, the patch >> in attachment will do the job in the mean time. Various >> optimizations are possible, I mentioned a few in comments, but it's >> out of nspluginwrapper 1.2.0 scope. > > This patch shouldn't affect stability? Only performance? Yes, this only affects performance as g_idle_add() is not really fast. Note I have not measured anything, this is a pure guess as this was the case with WebKit/Clutter. See e.g. Cases where it could cause crashes were if the PluginInstance was destroyed (through NPP_Destroy()) by the time NPN_InvalidateRect() was to be sent. But now that PluginInstances are refcounted and that if the NPP instance is destroyed, the other side receives a NULL pointer, this is OK because the other side won't call into the browser and return back to npviewer.bin and so on. Regards, Gwenole. From gb.public at free.fr Thu Dec 4 06:23:09 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Thu, 4 Dec 2008 07:23:09 +0100 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: <49376BEC.9050804@redhat.com> References: <49360EFC.2030307@redhat.com> <49376BEC.9050804@redhat.com> Message-ID: <3F44CA07-E31B-4609-B8CD-72C9B4BAD6D2@free.fr> Hi, Le 4 d?c. 08 ? 06:34, Warren Togami a ?crit : > Gwenole Beauchesne wrote: >> Hi, >> Le 3 d?c. 08 ? 05:45, Warren Togami a ?crit : >>> I see a case while playing Youtube videos, sometimes the plugin >>> turns into a grey box. npviewer.bin is no longer running. >>> Reloading the page once fails to recover. Reloading the second >>> time makes it work again. >> OK, I could reproduce the bug. Thanks. I think the patch to emit >> NPN_InvalidateRect() on idle (in another mail) should work for you >> too. > > BTW, what distro do you use with nspluginwrapper development and > testing? Initially, this was Mandriva Linux LE2005. But now that Flash requires glibc >= 2.4 and Firefox 3 also depends on GTk >= 2.6 (or 2.8 IIRC), it's only useful to build the distributed RPMs and test other plugins against an ancient Firefox too (1.0.2, 1.5.0.x, etc.). That machine 'aria' is an Athlon 64 (single core), kernel 2.6.11, glibc 2.3.6, libcurl.so.3 linked against openSSL. Now, current dev machine is 'macbook' running openSUSE 11.0 + 11.0- updates. So, it's a dual core system. However, it does not have sound working, though pulseaudio is probably running, I haven't checked. But concerning your problem, since you had WindowlessDisable=true, then the other patch won't help you. I got a crash in npviewer.bin for windowed plugins too through other tests and it could be an NObject refcounting problem. What happens is the NPObject returned for NPPVpluginScriptableNPObject is still accessed beyond NPP_Destroy() through the NPClass::Invalidate() member function. That NPObject refcount is 1 after its NPN_ReleaseObject() in NPP_Destroy() whereas I think it should have been 0. One fix to this problem would require the same strategy Martin used to "shutdown" the npruntime bridge, but at a finer granularity. i.e. keep track of NPObjects and their associated NPP instance. If their parent instance dies, mark the NPObjects as invalid (and release them actually -- memory leaks). The real fix would be to fix the NPObject refcounting problem. This is weird because all refcounts are synchronised from the browser side to the proxy object in npviewer.bin for each call passing an NPObject, and only the browser controls what happens to NPObject::referenceCount (unless the plugin does some magic with it directly). I don't know more yet as I went to sleep after that. ;-) Regards, Gwenole. From gb.public at free.fr Sat Dec 6 10:33:57 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sat, 6 Dec 2008 11:33:57 +0100 Subject: [PATCH] Fix XEMBED support References: <333CBE80-C893-4840-8516-2CF4ED01DBF7@FREE.FR> Message-ID: <158A6A05-5B07-44C3-9832-2A31B72F8321@free.fr> Hi, Here is a rework of the XEMBED hack code that fixes lost-events regressions. I learnt something crucial: without nspluginwrapper, i.e. in in- process plugins mode, the browser (and actually Gtk2) never destroys the plugin window, even on NPP_Destroy(), or GtkSocket destroy. Never. I assume the X server takes care of that on XCloseDisplay(). One thing is sure, the GtkSocket windows are never XDestroyWindow()'ed for the lifetime of the program. In out-of-process mode, i.e. with nspluginwrapper, a GtkSocket "destroy" will cause all windows in the hierarchy to be destroyed. In my opinion, that mismatch in behaviour is a bug in GtkPlug / GtkSocket implementation. So, I decided to mimic that behaviour, but in a smarter way. i.e. keep the GtkPlug / GtkSocket for correct XEMBED implementation (focus...) but never destroy the plugin window... until NPP_Destroy(). So far, the patch in attachment accomplishes this by catching the WM_DELETE_WINDOW event sent by the parent GtkSocket and simply don't propagate it into the actual window destruction code. Then, the NPP_Destroy() will trigger a normal window destruction through the GtkPlug destructor. Note: this patch depends on current Gtk2 implementations. If Gtk3 someday changes this process, then we probably will fail again. However, considering the way GtkPlug / GtkSocket / GdkWindow are implemented, I pretty doubt anybody would want to change that (even for the above-mentionned bug) as there are interesting ways to break existing applications. e.g. Firefox will start crashing without nspluginwrapper the same way nspluginwrapper is crashing today without the following patch... nspluginwrapper 1.2.0 is almost complete now. There is a remaining regression yet to be fixed (the one noticed by Warren). I have an idea I will test this weekend. Regards, Gwenole. -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-fix-XEMBED.patch Type: application/octet-stream Size: 4465 bytes Desc: not available URL: -------------- next part -------------- From gb.public at free.fr Sun Dec 7 23:41:51 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Mon, 8 Dec 2008 00:41:51 +0100 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: <3F44CA07-E31B-4609-B8CD-72C9B4BAD6D2@free.fr> References: <49360EFC.2030307@redhat.com> <49376BEC.9050804@redhat.com> <3F44CA07-E31B-4609-B8CD-72C9B4BAD6D2@free.fr> Message-ID: <008EAD16-FBDA-456C-A28D-3D3419E5A258@free.fr> Hi, Le 4 d?c. 08 ? 07:23, Gwenole Beauchesne a ?crit : > I got a crash in npviewer.bin for windowed plugins too through other > tests and it could be an NObject refcounting problem. What happens > is the NPObject returned for NPPVpluginScriptableNPObject is still > accessed beyond NPP_Destroy() through the NPClass::Invalidate() > member function. That NPObject refcount is 1 after its > NPN_ReleaseObject() in NPP_Destroy() whereas I think it should have > been 0. One fix to this problem would require the same strategy > Martin used to "shutdown" the npruntime bridge, but at a finer > granularity. i.e. keep track of NPObjects and their associated NPP > instance. If their parent instance dies, mark the NPObjects as > invalid (and release them actually -- memory leaks). The attached patch (from SVN) should fix this problem. Actually, it seems Flash's NPPVpluginScriptableNPObject needs to reference the NPP instance, and the plugin window too. So, PluginInstance bound to an NPObject are reference counted and plugin window destruction delayed to PluginInstance::finalize(). In practise, with Flash10, this occurs around NP_Shutdown(). Regards, Gwenole -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-fix-NPClass::Invalidate.patch Type: application/octet-stream Size: 3787 bytes Desc: not available URL: -------------- next part -------------- From gb.public at free.fr Sun Dec 7 23:52:15 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Mon, 8 Dec 2008 00:52:15 +0100 Subject: [PATCH] Fix invalid RPC after NPP_Destroy() In-Reply-To: <49360EFC.2030307@redhat.com> References: <49360EFC.2030307@redhat.com> Message-ID: <304D4EEA-10B1-4BF2-804E-0DA158703E75@free.fr> Hi, Le 3 d?c. 08 ? 05:45, Warren Togami a ?crit : > http://kojipkgs.fedoraproject.org/packages/nspluginwrapper/1.1.8/ > I have built 1.1.8 plus this patch for F10 and F11. > > I see a case while playing Youtube videos, sometimes the plugin > turns into a grey box. npviewer.bin is no longer running. > Reloading the page once fails to recover. Reloading the second time > makes it work again. I think I fixed this problem in SVN. Actually, there were two bugs: - NPPVpluginScriptableNPObject::Invalidate() was trying to access to the plugin window (that turned out to be destroyed in NPP_Destroy()) - rpc_method_invoke() requests initiated by the plugin did not synchronize well with the browser. Now, an RPC change makes sure we always bring the browser in a suitable state to receive calls from the plugins. Because of the RPC change, a new tarball will be available soon: 1.1.10 (1.2.0-RC). Re-wrapping plugins is mandatory. More details to come tomorrow. Regards, Gwenole. From gb.public at free.fr Mon Dec 8 22:44:41 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Mon, 8 Dec 2008 23:44:41 +0100 Subject: [ANN] nspluginwrapper 1.1.10 (1.2.0-RC) Message-ID: <0773693D-73C1-4F7B-974C-5F3BB909D376@free.fr> Hi, I have just released nspluginwrapper 1.1.10, thus marking the 1.2.0 Release Candidate. Changes from 1.1.8 to 1.1.10: * Fix NPPVpluginScriptableNPObject::Invalidate() * Fix condition for delayed NPN_ReleaseObject() call * Fix XEMBED (rework for lost events/focus regressions) * Fix RPC for calls initiated by the plugin (SYNC mode) * Fix invalid RPC after the plugin was NPP_Destroy()'ed Note, because of the RPC changes, it's mandatory to re-wrap your plugins. This is normally automatic on version changes (at the packaging level). Announcement and some (technical) words about the changes: Sources: From wtogami at redhat.com Tue Dec 9 05:09:32 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 09 Dec 2008 00:09:32 -0500 Subject: Fedora builds of nspluginwrapper-1.1.10 Message-ID: <493DFD8C.8040409@redhat.com> Great work Gwenole! http://kojipkgs.fedoraproject.org/packages/nspluginwrapper/1.1.10/ Preliminary testing indicates that this has fixed all known Flash crashes that I personally see. Others should test it and report findings, especially for non-Flash plugins. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Dec 10 07:01:58 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 10 Dec 2008 02:01:58 -0500 Subject: [ANN] nspluginwrapper 1.1.10 (1.2.0-RC) In-Reply-To: <0773693D-73C1-4F7B-974C-5F3BB909D376@free.fr> References: <0773693D-73C1-4F7B-974C-5F3BB909D376@free.fr> Message-ID: <493F6966.5050503@redhat.com> Gwenole Beauchesne wrote: > Hi, > > I have just released nspluginwrapper 1.1.10, thus marking the 1.2.0 > Release Candidate. > > Changes from 1.1.8 to 1.1.10: > * Fix NPPVpluginScriptableNPObject::Invalidate() > * Fix condition for delayed NPN_ReleaseObject() call > * Fix XEMBED (rework for lost events/focus regressions) > * Fix RPC for calls initiated by the plugin (SYNC mode) > * Fix invalid RPC after the plugin was NPP_Destroy()'ed > Congratulations, this is the first time I cannot manage to make Flash crash while running in nspluginwrapper. The only failures I see are: * Flash bugs like the one you can see on theonion.com videos. Adobe is aware of this bug. * If some other application (usually OSS) grabbed the entire sound device, pulseaudio fails to grab the sound device. In such cases Flash in nspluginwrapper running Flash fails with a grey box. No segfault, just gets stuck. This likely isn't nspluginwrapper's fault, and perhaps nsplugiwrapper helps it by preventing the entire browser from locking up? Not sure. Warren Togami wtogami at redhat.com From gb.public at free.fr Sun Dec 14 11:51:04 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sun, 14 Dec 2008 12:51:04 +0100 Subject: [PATCH] (partial) workaround for Firefox bug #469538 References: Message-ID: Hi, This a partial (read: nspluginwrapper part) fix for Firefox bug #469538 Actually, NPAPI docs lied for NPP_Destroy() and the NPP instance shall still be live after the call to the plugin function. i.e. nspluginwrapper should not free() the plugin instance in NPP_Destroy() because it may still be used later, in an NObject::Invalidate() function for example. I suspect Flash Player to expect NPP::pdata (i.e. its private plugin data) to still exist when the NPPVpluginScriptableNPObject::Invalidate() function is called. But since it was requested to delete its private data before, it's just pointing to garbage now. If we don't re-use the free()'ed block, that's fine and that's what happens most of the time. However, nspluginwrapper might allocate memory between NPP_Destroy() and NPClass::Invalidate(), e.g. while creating data for NPN_ReleaseObject() delayed call mechanism for another NPP instance. So, a crash can occur at this point because we re-used the previous NPP instance memory block but we still had a dangling pointer to it (the one stored in an NPPVpluginScriptableNPObject for example). Flash Player does the right assumptions according to the (unclear) NPAPI docs though and it's not its fault if Firefox requested to delete its private data too early. Note: I don't even know if Flash Player really falls into this scenario, this is a guess from traces of previous crashes with nspluginwrapper. With this patch, we are now on par with Firefox's behaviour. However, I still believe it's wrong/illogical to invalidate NPObjects after NPP_Destroy(). My rationale is if we pass an NPP instance to NPN_CreateObject(), this means we allow that instance, and most importantly its its private data, to be live until the NPObject is actually deallocated. If we put an NPP_Destroy() between those two events, the NPP instance will be dangling. And this is what happens currently, but works most of the time because we are lucky enough to not allocate memory that overwrites the previous block. Regards, Gwenole -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-dont-free-instance-in-NPP_Destroy.patch Type: application/octet-stream Size: 8148 bytes Desc: not available URL: -------------- next part -------------- From carjay at gmx.net Sat Dec 20 16:42:08 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat, 20 Dec 2008 17:42:08 +0100 Subject: usage of variable argument function pointer in npw-config.c Message-ID: <494D2060.4000503@gmx.net> Hi, I'm currently trying to debug why the 32 bit Flash Player 10 is crashing when used within nspluginwrapper on my Kubuntu 64 bit system with Firefox and during the course of getting more debug output I stumbled across an issue when building with optimization turned off (-O0). I'm using the latest svn sources. In this case, simply calling "npconfig -l" will crash with an "Illegal Instruction", for example in "static int list_plugin(const char *plugin_path, ...)" Since this function allows variable arguments, the compiler generates some extra assembler code (see http://www.x86-64.org/documentation/abi.pdf for detailed information). Problem is that this function is sometimes called indirectly inside a generic "process" function: "process_plugin_dir(plugin_dir, (is_plugin_cb)is_wrapper_plugin_0, (process_plugin_cb)list_plugin" Now, process_plugin_cb is typedef'ed as: "typedef int (*process_plugin_cb)(const char *plugin_path, NPW_PluginInfo *plugin_info);" So process_plugin_dir is not told that it receives a variable argument function pointer in the third argument and does not do the necessary setup before calling it. I see why the variable argument was added to allow "process_plugin_dir" to be generic in nature but using variable arguments this way seems problematic. Carsten From gb.public at free.fr Sun Dec 21 18:48:32 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sun, 21 Dec 2008 19:48:32 +0100 Subject: usage of variable argument function pointer in npw-config.c In-Reply-To: <494D2060.4000503@gmx.net> References: <494D2060.4000503@gmx.net> Message-ID: <8294B83B-911B-49B4-8CE2-43275DB5E7A4@free.fr> Hi, Le 20 d?c. 08 ? 17:42, Carsten Juttner a ?crit : > I'm currently trying to debug why the 32 bit Flash Player 10 is > crashing when used within nspluginwrapper on my Kubuntu 64 bit > system with Firefox and during the course of getting more debug > output I stumbled across an issue when building with optimization > turned off (-O0). Could you please tell me more about it? Were you able to reproduce it with WebKit or another version of Firefox? Currently, there is a problem left occuring only with Firefox 3.0.x. i.e. 2.0.x and 3.1b2 don't trigger the problem. Since I generally used the latter, I didn't catch it earlier. I could reproduce the problem with Flash9, Flash10 32- or 64-bit with Firefox 3.0.x from either openSUSE or Fedora. Steps to reproduce: 1. Start firefox 3.0.x and go to -- let's call that the reference page 2. Open a new tab with -- generally, this can crash here. If not, step down. 3. Open a new tab with and play a movie 4. Go to tab (2) and open e.g. 5. Go to tab (1), check the Flash animation is still alive. If not, redo steps 2, 4, 5. Flash is not crashing in some NPP_*() or NPN_*() function. Rather, it's crashing in a timeout. We are getting through a NULL pointer. This seems to be a jumptable (32-bit case), or a table with uint8_t values (64-bit case). In the latter case, a 32-bit value in a register is dereferenced as if it were a pointer. The location of the crash is not random, i.e. when the above-mentioned steps trigger the SIGSEGV, we always crash at the same location (instruction). In any case, this does not seem to be a free()'ed block that is accessed again because, in that case, valgrind would have noticed it (e.g. run with NPW_USE_VALGRIND=yes). BTW, talking about valgrind, I see a lot of occurrences of "uses of uninitialized variables" from Flash code. Those problems are not related, though. Sometimes, with G_SLICE=always-malloc and MALLOC_PERTURB_=B for example, I can notice some corruption (and even a SIGBUS at 0x42424242 -- the perturb canary), but this unfortunately is not systematic. So, I am wondering about the bug you are facing. It's probably the same, and it would be good if you had simpler steps. ;-) > I see why the variable argument was added to allow > "process_plugin_dir" to be generic in nature but using variable > arguments this way seems problematic. You are right, it's now fixed in SVN. BTW, I also created an nspluginwrapper-1.2-branch, please use it instead. Trunk contains some attempts to fix the remaining bug but it's a failure so far. Thanks, Gwenole. From carjay at gmx.net Thu Dec 25 15:40:33 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu, 25 Dec 2008 16:40:33 +0100 Subject: usage of variable argument function pointer in npw-config.c In-Reply-To: <8294B83B-911B-49B4-8CE2-43275DB5E7A4@free.fr> References: <494D2060.4000503@gmx.net> <8294B83B-911B-49B4-8CE2-43275DB5E7A4@free.fr> Message-ID: <4953A971.8010100@gmx.net> Hallo Gwenole, Gwenole Beauchesne wrote: > Le 20 d?c. 08 ? 17:42, Carsten Juttner a ?crit : > >> I'm currently trying to debug why the 32 bit Flash Player 10 is >> crashing when used within nspluginwrapper on my Kubuntu 64 bit system >> with Firefox and during the course of getting more debug output I >> stumbled across an issue when building with optimization turned off >> (-O0). > > Could you please tell me more about it? Were you able to reproduce it > with WebKit or another version of Firefox? Sorry for the late reply, it was my own fault, Flashplayer loads libcurl dynamically (since it supports several versions), unfortunately the error handling within Flashplayer is buggy and leaves the curl function pointers at NULL if the dlopen fails which leads to an instant crash when the plugin is initialized by the wrapper. So the real issue was me using a too recent version of libcurl which had an unmet dependency on a newer version of libldap. I could have checked that with ease using ldd but I thought it was a required import. I'm using Firefox 2.0.0.18 and Kubuntu Gutsy 7.10 and after using the correct 32 bit version of libcurl it worked flawlessly. Ah, at least it was worth it since some video streams that would stall with FlashPlayer9 play fine now. Thanks for all the effort, :) Regards, Carsten From gb.public at free.fr Thu Dec 25 16:04:05 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Thu, 25 Dec 2008 17:04:05 +0100 Subject: Firefox/Flash bug (Was: usage of variable argument function pointer in npw-config.c) In-Reply-To: <8294B83B-911B-49B4-8CE2-43275DB5E7A4@free.fr> References: <494D2060.4000503@gmx.net> <8294B83B-911B-49B4-8CE2-43275DB5E7A4@free.fr> Message-ID: Hi, Le 21 d?c. 08 ? 19:48, Gwenole Beauchesne a ?crit : > Currently, there is a problem left occuring only with Firefox 3.0.x. > i.e. 2.0.x and 3.1b2 don't trigger the problem. Since I generally > used the latter, I didn't catch it earlier. I could reproduce the > problem with Flash9, Flash10 32- or 64-bit with Firefox 3.0.x from > either openSUSE or Fedora. > > Steps to reproduce: > 1. Start firefox 3.0.x and go to > -- let's call that the reference page > 2. Open a new tab with -- generally, this can > crash here. If not, step down. > 3. Open a new tab with and play a movie > 4. Go to tab (2) and open e.g. > 5. Go to tab (1), check the Flash animation is still alive. If not, > redo steps 2, 4, 5. > > Flash is not crashing in some NPP_*() or NPN_*() function. Rather, > it's crashing in a timeout. We are getting through a NULL pointer. > This seems to be a jumptable (32-bit case), or a table with uint8_t > values (64-bit case). In the latter case, a 32-bit value in a > register is dereferenced as if it were a pointer. The location of > the crash is not random, i.e. when the above-mentioned steps trigger > the SIGSEGV, we always crash at the same location (instruction). Actually, it turns out to be a Firefox or Flash bug since I can really reproduce the problem without nspluginwrapper at all and plain 32-bit version. Software: - Firefox 3.0.x (from openSUSE 11.0-updates) - Flash Player 9.0.151 "debug" version If I follow the above-mentioned procedure, this can also result in a crash as follows: [...] Flash Player: Warning: environment variable G_FILENAME_ENCODING is set and is not UTF-8 ** ** Gtk:ERROR:(gtkplug.c:182):gtk_plug_set_is_child: assertion failed: (!GTK_WIDGET (plug)->parent) terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check /opt/firefox/firefox32-v3.0.3/run-mozilla.sh: line 131: 26310 Abandon "$prog" ${1+"$@"} I could not reproduce the problem with Firefox 3.1.x yet, neither with WebKit, so I guess I will spend a great time in checking the diffs... A backtrace shows the exception is thrown from Flash Player code. It would be great if a real debug version of Flash Player (i.e. with symbols) could be made available somehow. In the meantime, I will try to investigate further and write a workaround, if possible. Regards, Gwenole. From gb.public at free.fr Thu Dec 25 17:40:00 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Thu, 25 Dec 2008 18:40:00 +0100 Subject: Firefox/Flash bug (Was: usage of variable argument function pointer in npw-config.c) In-Reply-To: References: <494D2060.4000503@gmx.net> <8294B83B-911B-49B4-8CE2-43275DB5E7A4@free.fr> Message-ID: <5A36A849-F22B-4448-A1CE-8A4047DC525F@free.fr> Hi, > I could not reproduce the problem with Firefox 3.1.x yet, neither > with WebKit, so I guess I will spend a great time in checking the > diffs... A backtrace shows the exception is thrown from Flash Player > code. It would be great if a real debug version of Flash Player > (i.e. with symbols) could be made available somehow. > > In the meantime, I will try to investigate further and write a > workaround, if possible. I think I determined the cause: Flash Block. I have uninstalled it, and the problems vanished. Note: even if the extension is disabled (i.e. always play Flash), it seems to conflict somehow with Flash Player and causing all sort of side effects leading to this issue. I don't know how Firefox extensions work, but are they specific to a Firefox version it was installed on, thus possibly explaining why I could not reproduce the problems with neither Firefox v2 nor Firefox v3.1b2? Otherwise, this means Firefox trunk back to 2008/05/01had a fix for this problem. Note, I said 2008/05/01 because I have not tried earlier versions. So, based on those new findings, I won't hold the release of nspluginwrapper 1.2.0 any further. I will do a new round of testing with current nspluginwrapper-1.2-branch and release from that. IOW, I won't bother fixing/workarounding this issue at this time as it's not nspluginwrapper but rather triggered by a combination of Firefox and FlashBlock extensions. Oh, and something I have just realized: this would also explain why Firefox wanted Flash's NPPVpluginScriptableNPObject and not WebKit. I will probably just open a bug at mozilla.org and let them determine who is the actual culprit among Firefox 3.0.x, Flash Player and Flash Block. Regards, Gwenole. From asac at jwsdot.com Fri Dec 26 14:30:23 2008 From: asac at jwsdot.com (Alexander Sack) Date: Fri, 26 Dec 2008 15:30:23 +0100 Subject: Firefox/Flash bug (Was: usage of variable argument function pointer in npw-config.c) In-Reply-To: <5A36A849-F22B-4448-A1CE-8A4047DC525F@free.fr> References: <494D2060.4000503@gmx.net> <8294B83B-911B-49B4-8CE2-43275DB5E7A4@free.fr> <5A36A849-F22B-4448-A1CE-8A4047DC525F@free.fr> Message-ID: <20081226143023.GE23540@jwsdot.com> On Thu, Dec 25, 2008 at 06:40:00PM +0100, Gwenole Beauchesne wrote: > Hi, > >> I could not reproduce the problem with Firefox 3.1.x yet, neither with >> WebKit, so I guess I will spend a great time in checking the diffs... A >> backtrace shows the exception is thrown from Flash Player code. It >> would be great if a real debug version of Flash Player (i.e. with >> symbols) could be made available somehow. >> >> In the meantime, I will try to investigate further and write a >> workaround, if possible. > > I think I determined the cause: Flash Block. I have uninstalled it, and > the problems vanished. Note: even if the extension is disabled (i.e. > always play Flash), it seems to conflict somehow with Flash Player and > causing all sort of side effects leading to this issue. > > I don't know how Firefox extensions work, but are they specific to a > Firefox version it was installed on, thus possibly explaining why I > could not reproduce the problems with neither Firefox v2 nor Firefox > v3.1b2? Otherwise, this means Firefox trunk back to 2008/05/01had a fix > for this problem. Note, I said 2008/05/01 because I have not tried > earlier versions. You should check whether flashblock can be installed in ffox 3.1. if thats not the case you can try set the hidden pref: extensions.checkCompatibility to false ... - Alexander From gb.public at free.fr Fri Dec 26 15:48:34 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Fri, 26 Dec 2008 16:48:34 +0100 Subject: [ANN] nspluginwrapper 1.2.0 Message-ID: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> Hi, I have just released nspluginwrapper 1.2.0. Thanks to everyone for testing snapshots during the development phase. Here are the changes since 1.1.10: * Drop obsolete the mkruntime script * Use valgrind if NPW_USE_VALGRIND=yes * Add support for SunStudio compilers * Add support for Flash Player 10 on OpenSolaris 2008.11 * Fix build on non-Linux platforms * Fix NPP_Destroy() to keep NPP instances longer * Fix NPP_Destroy() to destroy the plugin windows * A branch was also created for 1.2.x subreleases, if any: * Online annoucement (and more details): Regards, Gwenole. From wtogami at redhat.com Fri Dec 26 21:47:12 2008 From: wtogami at redhat.com (Warren Togami) Date: Fri, 26 Dec 2008 16:47:12 -0500 Subject: [ANN] nspluginwrapper 1.2.0 In-Reply-To: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> Message-ID: <495550E0.5060507@redhat.com> Great work Gwenole. I didn't build this yet because our patches conflict in ways that Stransky understands a lot more than me. http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/ Might it be possible for you to integrate some of our build related patches in a future version? http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.2-event.patch?revision=1.1 What does this do? Not suitable for upstream? Our configure and Makefile patches are not suitable for upstream directly, but perhaps you could include stuff in the upstream automake/autoconf stuff to make it easier for us to achieve the same result without huge and ugly patches? Perhaps configure --singlearchbuild? -MOZILLA_CFLAGS = -I$(SRC_PATH)/npapi -I$(SRC_PATH)/npapi/nspr +MOZILLA_CFLAGS = $(GECKO_CFLAGS) +MOZILLA_LDFLAGS = $(GECKO_LDFLAGS) Another configure option to specify MOZILLA_CFLAGS so we can do this without patching the Makefile? http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.8-directory.patch?view=log Why is this not upstream? Warren Togami wtogami at redhat.com From gb.public at free.fr Sat Dec 27 07:02:31 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sat, 27 Dec 2008 08:02:31 +0100 Subject: [PATCH] Fix NPN_GetStringIdentifiers() Message-ID: <3D74F0A6-EE4C-4368-8A9A-B08DC108B982@free.fr> Hi, This (silly) problem was triggered by the VLC plugin. -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-fix-NPN_GetStringIdentifiers. Type: application/octet-stream Size: 542 bytes Desc: not available URL: -------------- next part -------------- From gb.public at free.fr Sat Dec 27 07:04:08 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sat, 27 Dec 2008 08:04:08 +0100 Subject: [PATCH] Standalone player fixes Message-ID: <4B6C4AC7-C1E4-46CB-89A6-99186867DFFD@free.fr> Hi, Here is a minor fix to the standalone player, in case we could not create a stream. We were trying to dereference data that was just free()'ed since NULL was not returned on error. -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-standalone-player-fixes.patch Type: application/octet-stream Size: 464 bytes Desc: not available URL: -------------- next part -------------- From gb.public at free.fr Sat Dec 27 07:28:37 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sat, 27 Dec 2008 08:28:37 +0100 Subject: [ANN] nspluginwrapper 1.2.0 In-Reply-To: <495550E0.5060507@redhat.com> References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> <495550E0.5060507@redhat.com> Message-ID: <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> Hi, Le 26 d?c. 08 ? 22:47, Warren Togami a ?crit : > http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/ > Might it be possible for you to integrate some of our build related > patches in a future version? Yes, I will check. I wanted to include the mozilla-plugin pkg-config changes but I forgot and initially failed to find a correct configure option. --with-mozilla-pkgconfig, --with-gecko-pkgconfig, etc. ? > http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.2-event.patch?revision=1.1 > What does this do? Not suitable for upstream? Actually, nothing for Gtk2-based plugins like Adobe Reader or Adobe Flash. The initial intent was to purge all pending Xt timer or input events when they are available. I still plan another patch for 1.3.x series (1.4.0) that will also kill the Xt timer when it's not needed at all (Gtk2 plugins). This will avoid switching from sleep state too much, as initially intended in one of your bug reports. > http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.8-directory.patch?view=log > Why is this not upstream? IIRC, your patch is more to change nspluginwrapper libdirs actually, isn't it? i.e. have /usr/lib/nspluginwrapper and /usr/lib64/ nspluginwrapper. This approach is very specific to Linux i386/x86_64 architectures. I still prefer the NPW_PREFIX/ARCH/OS/ hierarchy because it's also desirable to support Windows plugins, and the run- time will be available in */i386/windows/. Maybe /usr/libexec is a better location? Though, neither FHS nor LSB mention it for Linux IIRC. Regards, Gwenole. From gb.public at free.fr Sat Dec 27 10:14:05 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sat, 27 Dec 2008 11:14:05 +0100 Subject: Tentative roadmap Message-ID: <9646FE10-6307-4F47-9673-62ADDBE545E8@free.fr> Hi, Here is a desired roadmap, feature wise. There is no timeline because I never match them, it depends on my spare time. * 1.4.0 - Release focus: various optimizations (mainly for energy efficiency) - 1.3.0: drop Xt timer glue when not necessary, NPObject props caching, malloc-check code - 1.3.2: "local" streams handling, i.e. don't round-trip to the browser, delegate that to npviewer.bin (i.e. share code with npplayer) - 1.3.4: various satellite changes, e.g. system configuration files -> /etc/sysconfig/nspluginwrapper/*, could be useful for Transitive "profiles". - 1.3.x: as many releases as required to reach stable state * 2.0.0 - Release focus: public API, offscreen redirection - 1.9.0: new build system, convert to C++ - 1.9.2: offscreen redirection (Clutter/Moblin2) - 1.9.4: reworked and public API, sample integration in Firefox for "wrap-less" plugins management - 1.9.x: as many releases as required to reach stable state * 2.2.0 - Release focus: other host/target OS support - 2.1.0: MacOS X host/targets support - 2.1.2: Windows targets support in Linux - 2.1.4: Windows host support if I am motivated enough - 2.1.x: as many releases as required to reach stable state Everything up to 2.0.0 + 2.1.2 item is what I currently have in mind clearly (large parts) and experimental bits in practise (a few parts). i.e. it will depend on how fast I am good at dumping my mind to code and/or how good my initial thoughts were. Comments welcome. Regards, Gwenole. From wtogami at redhat.com Sun Dec 28 02:27:29 2008 From: wtogami at redhat.com (Warren Togami) Date: Sat, 27 Dec 2008 21:27:29 -0500 Subject: [ANN] nspluginwrapper 1.2.0 In-Reply-To: <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> <495550E0.5060507@redhat.com> <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> Message-ID: <4956E411.4020504@redhat.com> Gwenole Beauchesne wrote: >> http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.8-directory.patch?view=log >> >> Why is this not upstream? > > IIRC, your patch is more to change nspluginwrapper libdirs actually, > isn't it? i.e. have /usr/lib/nspluginwrapper and > /usr/lib64/nspluginwrapper. This approach is very specific to Linux > i386/x86_64 architectures. I still prefer the NPW_PREFIX/ARCH/OS/ > hierarchy because it's also desirable to support Windows plugins, and > the run-time will be available in */i386/windows/. Maybe /usr/libexec is > a better location? Though, neither FHS nor LSB mention it for Linux IIRC. > /usr/libexec is a GNU standard, but it is not appropriate for this at all. nspluginwrapper on Fedora/RHEL has independent builds and binary packages that can be installed on i386 and x86_64. For example, Fedora x86_64 installs only nspluginwrapper.x86_64 by default. nspluginwrapper.x86_64: /etc/sysconfig/nspluginwrapper /usr/bin/mozilla-plugin-config /usr/lib64/mozilla/plugins-wrapped /usr/lib64/mozilla/plugins-wrapped/npwrapper.so /usr/lib64/nspluginwrapper /usr/lib64/nspluginwrapper/npconfig /usr/lib64/nspluginwrapper/npplayer /usr/lib64/nspluginwrapper/npviewer /usr/lib64/nspluginwrapper/npviewer.bin /usr/lib64/nspluginwrapper/npwrapper.so /usr/lib64/nspluginwrapper/nspluginplayer /usr/lib64/nspluginwrapper/plugin-config /usr/share/doc/nspluginwrapper-1.1.10 /usr/share/doc/nspluginwrapper-1.1.10/COPYING /usr/share/doc/nspluginwrapper-1.1.10/NEWS /usr/share/doc/nspluginwrapper-1.1.10/README nspluginwrapper.i386: /etc/sysconfig/nspluginwrapper /usr/bin/mozilla-plugin-config /usr/lib/mozilla/plugins-wrapped /usr/lib/mozilla/plugins-wrapped/npwrapper.so /usr/lib/nspluginwrapper /usr/lib/nspluginwrapper/npconfig /usr/lib/nspluginwrapper/npplayer /usr/lib/nspluginwrapper/npviewer /usr/lib/nspluginwrapper/npviewer.bin /usr/lib/nspluginwrapper/npwrapper.so /usr/lib/nspluginwrapper/nspluginplayer /usr/lib/nspluginwrapper/plugin-config /usr/share/doc/nspluginwrapper-1.1.10 /usr/share/doc/nspluginwrapper-1.1.10/COPYING /usr/share/doc/nspluginwrapper-1.1.10/NEWS /usr/share/doc/nspluginwrapper-1.1.10/README It would be great if your upstream tarball had configure options to allow building only a single arch for installation into a target libdir in this manner. We would like to be able to build nspluginwrapper for Fedora without giant patches that deviate from the upstream source. By making it configure options it need not change the way it builds and installs on other operating systems. Warren Togami wtogami at redhat.com From gb.public at free.fr Sun Dec 28 11:52:11 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Sun, 28 Dec 2008 12:52:11 +0100 Subject: [PATCH] Fix for VLC plug-in support Message-ID: Hi, This patch (against 1.2-branch) fixes support of the VLC plug-in. Actually, VLC was making a local copy of the NPWindow passed to NPP_SetWindow(). However, it failed to copy the NPSetWindowCallbackStruct too. So, it then expected/depended on the NPWindow::ws_info pointer to not change for the lifetime of the window. A free()'ed structure was accessed in their Redraw() function, called from a timer. They really should not depend on a fixed-location ws_info, as it could also be in stack location. Especially since they apparently need it only to get the window display. IMHO, they should create a new VlcPlugin::getDisplay() function to access a cached pointer to current display, or at least make a copy of ws_info too. -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-fix-vlc.patch Type: application/octet-stream Size: 4163 bytes Desc: not available URL: -------------- next part -------------- From gb.public at free.fr Mon Dec 29 07:58:20 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Mon, 29 Dec 2008 08:58:20 +0100 Subject: multi-path (Was: [ANN] nspluginwrapper 1.2.0) In-Reply-To: <4956E411.4020504@redhat.com> References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> <495550E0.5060507@redhat.com> <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> <4956E411.4020504@redhat.com> Message-ID: <0FAC5EAE-635A-4F46-AE4D-8B5266A80703@free.fr> Hi, Le 28 d?c. 08 ? 03:27, Warren Togami a ?crit : > Gwenole Beauchesne wrote: >>> http://cvs.fedoraproject.org/viewvc/rpms/nspluginwrapper/F-10/nspluginwrapper-1.1.8-directory.patch?view=log >>> Why is this not upstream? >> IIRC, your patch is more to change nspluginwrapper libdirs >> actually, isn't it? i.e. have /usr/lib/nspluginwrapper and /usr/ >> lib64/nspluginwrapper. This approach is very specific to Linux i386/ >> x86_64 architectures. I still prefer the NPW_PREFIX/ARCH/OS/ >> hierarchy because it's also desirable to support Windows plugins, >> and the run-time will be available in */i386/windows/. Maybe /usr/ >> libexec is a better location? Though, neither FHS nor LSB mention >> it for Linux IIRC. > > /usr/libexec is a GNU standard, but it is not appropriate for this > at all. nspluginwrapper on Fedora/RHEL has independent builds and > binary packages that can be installed on i386 and x86_64. For > example, Fedora x86_64 installs only nspluginwrapper.x86_64 by > default. And why is the current hierarchy not appropriate? Everything is well separated and it should not even be a packaging tool problem. AFAIK, pkglibdir/noarch/npviewer is a shell script so it is not assigned any color. In that case, the conflict-check is relaxed and does not include timestamps. It is already possible to build native arch trees: configure --target- cpu=%{_arch}. In that case, 32-/64-bit build at once is disabled and you only get "native" binaries, though in pkglibdir/ARCH/linux/. Regards, Gwenole. From wtogami at redhat.com Mon Dec 29 09:27:52 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Dec 2008 04:27:52 -0500 Subject: multi-path (Was: [ANN] nspluginwrapper 1.2.0) In-Reply-To: <0FAC5EAE-635A-4F46-AE4D-8B5266A80703@free.fr> References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> <495550E0.5060507@redhat.com> <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> <4956E411.4020504@redhat.com> <0FAC5EAE-635A-4F46-AE4D-8B5266A80703@free.fr> Message-ID: <49589818.1040803@redhat.com> Gwenole Beauchesne wrote: > > It is already possible to build native arch trees: configure > --target-cpu=%{_arch}. In that case, 32-/64-bit build at once is > disabled and you only get "native" binaries, though in > pkglibdir/ARCH/linux/. > OK, this sounds better, except it violates our distribution's packaging standards so we cannot do it exactly this way. Warren Togami wtogami at redhat.com From gb.public at free.fr Mon Dec 29 15:52:51 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Mon, 29 Dec 2008 16:52:51 +0100 Subject: [PATCH] Add multi-path support In-Reply-To: <49589818.1040803@redhat.com> References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> <495550E0.5060507@redhat.com> <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> <4956E411.4020504@redhat.com> <0FAC5EAE-635A-4F46-AE4D-8B5266A80703@free.fr> <49589818.1040803@redhat.com> Message-ID: Hi, Le 29 d?c. 08 ? 10:27, Warren Togami a ?crit : > Gwenole Beauchesne wrote: >> It is already possible to build native arch trees: configure -- >> target-cpu=%{_arch}. In that case, 32-/64-bit build at once is >> disabled and you only get "native" binaries, though in pkglibdir/ >> ARCH/linux/. > > OK, this sounds better, except it violates our distribution's > packaging standards so we cannot do it exactly this way. I have attached a patch derived from trunk, it's not applied to 1.2- branch yet. viewer_paths="/usr/lib/nspluginwrapper" %if "%{_lib}" != "lib" viewer_paths="%{_libdir}/nspluginwrapper:$viewer_paths" %endif configure --target-cpu=%{_arch} --pkglibdir=%{_libdir}/nspluginwrapper --viewer-paths="$viewer_paths" should provide the desired effect. Only the default behaviour will be supported/tested in the future though. -------------- next part -------------- A non-text attachment was scrubbed... Name: nspluginwrapper-multi-path.patch Type: application/octet-stream Size: 25310 bytes Desc: not available URL: -------------- next part -------------- From wtogami at redhat.com Mon Dec 29 20:22:39 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Dec 2008 15:22:39 -0500 Subject: [PATCH] Add multi-path support In-Reply-To: References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> <495550E0.5060507@redhat.com> <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> <4956E411.4020504@redhat.com> <0FAC5EAE-635A-4F46-AE4D-8B5266A80703@free.fr> <49589818.1040803@redhat.com> Message-ID: <4959318F.7090705@redhat.com> Gwenole Beauchesne wrote: > Hi, > > Le 29 d?c. 08 ? 10:27, Warren Togami a ?crit : > >> Gwenole Beauchesne wrote: >>> It is already possible to build native arch trees: configure >>> --target-cpu=%{_arch}. In that case, 32-/64-bit build at once is >>> disabled and you only get "native" binaries, though in >>> pkglibdir/ARCH/linux/. >> >> OK, this sounds better, except it violates our distribution's >> packaging standards so we cannot do it exactly this way. > > I have attached a patch derived from trunk, it's not applied to > 1.2-branch yet. > > viewer_paths="/usr/lib/nspluginwrapper" > %if "%{_lib}" != "lib" > viewer_paths="%{_libdir}/nspluginwrapper:$viewer_paths" > %endif > configure --target-cpu=%{_arch} --pkglibdir=%{_libdir}/nspluginwrapper > --viewer-paths="$viewer_paths" > > should provide the desired effect. Only the default behaviour will be > supported/tested in the future though. > I haven't built this yet, but is this sufficient for the /usr/lib64 nspluginwrapper plugin to find the other npviewer? Warren Togami wtogami at redhat.com From gb.public at free.fr Tue Dec 30 07:42:41 2008 From: gb.public at free.fr (Gwenole Beauchesne) Date: Tue, 30 Dec 2008 08:42:41 +0100 Subject: [PATCH] Add multi-path support In-Reply-To: <4959318F.7090705@redhat.com> References: <949CAE34-3C34-4A6C-94F6-88A33660F901@free.fr> <495550E0.5060507@redhat.com> <53D419B5-EE4C-49F8-9977-04140AB3CD17@free.fr> <4956E411.4020504@redhat.com> <0FAC5EAE-635A-4F46-AE4D-8B5266A80703@free.fr> <49589818.1040803@redhat.com> <4959318F.7090705@redhat.com> Message-ID: <9938A4F7-CC60-4A4F-8204-ED8BC4174CBE@free.fr> Hi, Le 29 d?c. 08 ? 21:22, Warren Togami a ?crit : >> viewer_paths="/usr/lib/nspluginwrapper" >> %if "%{_lib}" != "lib" >> viewer_paths="%{_libdir}/nspluginwrapper:$viewer_paths" >> %endif >> configure --target-cpu=%{_arch} --pkglibdir=%{_libdir}/ >> nspluginwrapper --viewer-paths="$viewer_paths" >> should provide the desired effect. Only the default behaviour will >> be supported/tested in the future though. > > I haven't built this yet, but is this sufficient for the /usr/lib64 > nspluginwrapper plugin to find the other npviewer? I have not strictly tested this scenario, but yes, provided you mention all valid viewer paths for other arches. This is for npconfig, the tool that generates a wrapped plugin. Then, at run-time, the path to the actual viewer is now included in the (patched) binary, see NPW_PluginInfo::viewer_path[]. It should work as desired.