From stransky at redhat.com Fri Apr 1 06:42:46 2011 From: stransky at redhat.com (Martin Stransky) Date: Fri, 01 Apr 2011 08:42:46 +0200 Subject: Nspluginwrapper Update Status In-Reply-To: References: Message-ID: <4D9573E6.70804@redhat.com> On 04/01/2011 01:42 AM, David A Benjamin wrote: > First is a fairly boring batch from Fedora that decreases the RPC > timeout from 30 seconds to 10. The git commit says "Changed RPM [sic] > timeout to 10 second, should prevent long browser hangs." Martin, you're > on this list right? What was the original reason for this change? Both > numbers are absurdly long for UI. Was this in case the plugin process > exited or hung? If exited, the wrapper instead detect a crashed viewer > better. If hung, it's not really hanging any more than would normally. > I'd like to not focus on trying to improve the plugin and only recommend > nspluginwrapper when your plugin is the wrong architecture. Both > Chromium and Firefox already push plugins out of process, presumably > already with hang/timeout logic, so this is just an extra source of bugs > (and generally makes good on promises there). I think it was because plugins hangs sometimes (in NPP_SetWindow for instance) and whole browser is frozen and waits when plugin finishes (NPAPI calls are synced). Some hang detector would be great here. > Looking at Fedora's situation however, what if instead npw-config.c gets > hacked to pieces and we add some npconfig binary with commands like > npconfig is_plugin PLUGIN, npconfig is_wrapper WRAPPER, npconfig > install_wrapper PLUGIN WRAPPER, etc. Then Fedora's plugin-config tool > can be written in shell (or Python or whatever), and likewise Debian and > Ubuntu can write their own things. Upstream can probably provide one > compatible with the original for distros that didn't change it and maybe > improve it later. I'd love to stop this madness where every distro does > paths differently, but I don't think nspluginwrapper can fix this. And > in the meantime, people have not yet agreed on a coherant way to > discover and install multiarch plugins. I wrote the plugin-config tool because we wanted to install the plugins when firefox was starting and it was meant to be as fast as possible. I'd use a combination of npw-config and python/bash script today. The speed is no longer an issue and plugin-config duplicates many parts of npw-config. Plus plugin-config is too complicated - it tries to detect changes and do only necessary replacements. So the new tool may just remove all linked/wrapped plugins and wrap/link them again. > So, what are folks' thoughts about that? And if this is reasonable, > should it be done now, or would it be better to save this for 1.6.0? It > probably wouldn't be an insane amount of work, but it does also mean > more friction for packagers to build the new ones. And possibly more > sources for incompatibilities. > > I think this issue is the last on my list, other than further > buildsystem cleanup (--with-lib32 is completely unused, and > --with-lib64's remaining usage could maybe be replaced with LIBDIR or > something). I was also going to see what other nspluginwrapper bugs in > Chromium's tracker I can fix. And then I guess I can maybe make some > final attempt to contact the original author and eventually get a 1.4.0 > out for all to enjoy. Thanks for your work on this project! I don't mind to take any changes and merge them with recent Fedora packages. And I'd love to get rid of plugin-config ;-) ma. From davidben at mit.edu Sat Apr 2 07:54:20 2011 From: davidben at mit.edu (David A Benjamin) Date: Sat, 2 Apr 2011 03:54:20 -0400 (EDT) Subject: Nspluginwrapper Update Status In-Reply-To: <4D9573E6.70804@redhat.com> References: <4D9573E6.70804@redhat.com> Message-ID: On Fri, 1 Apr 2011, Martin Stransky wrote: > I think it was because plugins hangs sometimes (in NPP_SetWindow for > instance) and whole browser is frozen and waits when plugin finishes (NPAPI > calls are synced). Some hang detector would be great here. Mmm. Well, this only freezes the renderer processes in Chromium. Seems Firefox freezes the whole thing. Meh, I went ahead and took the patch. Cutting down on distribution patches was an explicit goal of this work after all. :-) I don't really care and can't imagine it'd cause any trouble that a 30 second timeout wouldn't also have. I don't know off-hand if either browser has hang detectors for plugins. (Chromium does have one for renderers.) I do think this should be the browser's job though. Both browsers already push plugins out-of-process, and a hanging plugin is as legitimate of a problem without nspluginwrapper as with. Browser-level hang logic should work just fine for us. They also can do a far better job (e.g. "A plugin is causing foobar page to be slow, kill it?", fading the tab out to black, some other crazy thing). (Oh, I guess I never disclaimed this explicitly: should anybody care, I'm a student who recently interned with Google on Chrome and still occasionally contributes to Chromium. Of course my nspluginwrapper work is tested on Firefox and written with it in mind (even fixed a bug triggered by Arora this week). But I can't promise they'll both get equal testing, seeing as one of them is my primary browser and the other isn't.) > I wrote the plugin-config tool because we wanted to install the plugins when > firefox was starting and it was meant to be as fast as possible. I'd use a > combination of npw-config and python/bash script today. The speed is no > longer an issue and plugin-config duplicates many parts of npw-config. Plus > plugin-config is too complicated - it tries to detect changes and do only > necessary replacements. So the new tool may just remove all linked/wrapped > plugins and wrap/link them again. Huh, interesting. I gather this is why there's something about setuid in your git repo? (I still haven't looked at plugin-config in detail yet.) I wonder if that'll be problematic if it's replaced with a script. This existing tool also does the partial update thing which I agree should be dropped. Among other things, it currently only records the upstream version number of a wrapper. On a distro which uses the existing update mechanism, any patch which changes the wrapper help will not update any wrappers, breaking those plugins. If plugin-config has its own logic, it's possible you don't have this bug. (And since it's been ages since the last upstream version number bump, I suspect few have actually tested their wrapper upgrade paths. Perhaps that's an argument for getting this dealt with in my first release because packagers will want to revisit the migration path anyway.) > Thanks for your work on this project! I don't mind to take any changes > and merge them with recent Fedora packages. And I'd love to get rid of > plugin-config ;-) Thanks for the support. :-) I should ping the Debian and Ubuntu maintainers, (Hey guys, do you happen to be on this list already?), so they're aware of this effort and can chime in about what they need for wrapper management. David From stransky at redhat.com Tue Apr 5 11:14:57 2011 From: stransky at redhat.com (Martin Stransky) Date: Tue, 05 Apr 2011 13:14:57 +0200 Subject: Nspluginwrapper Update Status In-Reply-To: References: <4D9573E6.70804@redhat.com> Message-ID: <4D9AF9B1.7010701@redhat.com> On 04/02/2011 09:54 AM, David A Benjamin wrote: > On Fri, 1 Apr 2011, Martin Stransky wrote: >> I think it was because plugins hangs sometimes (in NPP_SetWindow for >> instance) and whole browser is frozen and waits when plugin finishes >> (NPAPI calls are synced). Some hang detector would be great here. > (Oh, I guess I never disclaimed this explicitly: should anybody care, > I'm a student who recently interned with Google on Chrome and still > occasionally contributes to Chromium. Of course my nspluginwrapper work > is tested on Firefox and written with it in mind (even fixed a bug > triggered by Arora this week). But I can't promise they'll both get > equal testing, seeing as one of them is my primary browser and the other > isn't.) To be honest I don't care about the timeout. >> I wrote the plugin-config tool because we wanted to install the >> plugins when firefox was starting and it was meant to be as fast as >> possible. I'd use a combination of npw-config and python/bash script >> today. The speed is no longer an issue and plugin-config duplicates >> many parts of npw-config. Plus plugin-config is too complicated - it >> tries to detect changes and do only necessary replacements. So the new >> tool may just remove all linked/wrapped plugins and wrap/link them again. > > Huh, interesting. I gather this is why there's something about setuid in > your git repo? (I still haven't looked at plugin-config in detail yet.) > I wonder if that'll be problematic if it's replaced with a script. > > This existing tool also does the partial update thing which I agree > should be dropped. Among other things, it currently only records the > upstream version number of a wrapper. On a distro which uses the > existing update mechanism, any patch which changes the wrapper help will > not update any wrappers, breaking those plugins. If plugin-config has > its own logic, it's possible you don't have this bug. > > (And since it's been ages since the last upstream version number bump, I > suspect few have actually tested their wrapper upgrade paths. Perhaps > that's an argument for getting this dealt with in my first release > because packagers will want to revisit the migration path anyway.) We use the binary tool because we want to allow common users to run the plugin updates, so the tool is run from firefox starting script and ensures that the plugins are in correct shape. And IIRC you can't run any script as setuid. From gb.devel at gmail.com Wed Apr 6 14:13:18 2011 From: gb.devel at gmail.com (Gwenole Beauchesne) Date: Wed, 6 Apr 2011 16:13:18 +0200 Subject: nspluginwrapper status Message-ID: Hi, I wanted to write about this for a long time but I didn't have a chance yet. I am sorry, but I am taking the opportunity of this short vacation to tell a few words about it. As you probably noticed, my web server does not exist any more for some time. More specifically, the server suffered an (reportedly) HW failure on December, 25th 2009 (nice gift...). Even worse, the ISP had changed the backup server to a new one but the older backups are also gone. :-/ I found an old backup (~2006) at home but this won't be enough. I remember I once generated an svn dump for RH people too but since I don't find anything in my archives, I believe it stayed in the (now dead) server. However, what I still have are older source tarballs. I also wondered if it wouldn't be possible to extract the data from the Google cache, but I didn't have the time to investigate further. Future. I saw David volunteered to become the new upstream maintainer. I have no objections, unless Martin wants to take the role since he has been working on the project for a longer time. Thanks. Ideas. * The LSB stuff for ia32 can indeed die. It was initially desired so that building on Debian systems is less effort. On other systems, this is a non issue since they can easily build 32-/64-bit binaries or at least install i386 packages on x86_64 systems. * I have an (awful) patch I wrote ~3 years ago that makes it possible to render to OpenGL. It was initially useful to allow for Flash Player integration to a Clutter object. Not a real-world use case, so I doubt this would interest anyone. Besides, I am not even sure this works with new Flash Player binaries (>= 10.0). I wished I could dedicate more time to my original projects, but I was not capable enough to get it. I am sorry for that. Regards, Gwenole. From davidben at mit.edu Thu Apr 21 05:21:56 2011 From: davidben at mit.edu (David A Benjamin) Date: Thu, 21 Apr 2011 01:21:56 -0400 (EDT) Subject: nspluginwrapper status In-Reply-To: References: Message-ID: Hi Gwenole, Thanks for the update. > I saw David volunteered to become the new upstream maintainer. I have > no objections, unless Martin wants to take the role since he has been > working on the project for a longer time. Thanks. Martin, if you want to take the role instead, go for it (and feel free pull what you want from my repo); I won't be annoyed. Less work for me to do. :-D Otherwise, I'm happy to do it, and glad to have your blessing, Gwenole. It felt slightly weird before as to whether I should at least rename my fork or something... > I found an old backup (~2006) at home but this won't be enough. I > remember I once generated an svn dump for RH people too but since I > don't find anything in my archives, I believe it stayed in the (now > dead) server. However, what I still have are older source tarballs. I > also wondered if it wouldn't be possible to extract the data from the > Google cache, but I didn't have the time to investigate further. I actually found most of the existing tarballs from archive.org and distribution archives. I think I'm just missing 1.1.6 and 1.1.8. https://github.com/davidben/nspluginwrapper/commits/upstream (Speaking of which, I probably ought to filter the repo and set the commit authors more accurately. Though there's enough history now that it may be messy. I really should have done that from the start.) Changes since 1.3.0 would be useful though, if you have them. The best I've found is an Ohloh listing, but it gives only diffstats. (But that may be enough to recreate things.) In fact, it seems you had already done one of my planned changes. https://www.ohloh.net/p/12179/commits https://www.ohloh.net/p/12179/commits/32997620 > * The LSB stuff for ia32 can indeed die. It was initially desired so > that building on Debian systems is less effort. On other systems, this > is a non issue since they can easily build 32-/64-bit binaries or at > least install i386 packages on x86_64 systems. (Aha! I thought it was Debian...) Yeah, I think Debian and Ubuntu are (FINALLY!) starting to transition to their grand new multiarch plan. I'll probably deal with that for 1.6.0 or later. I already have plenty of changes lined up for 1.4.0. Speaking of which, hopefully this weekend or so I'll put out a 1.3.2 as a beta for 1.4.0. I do want a beta for people on development versions of distros or so to test; there are some invasive changes that should be stressed on more than just my machine. (If anyone has a chance to sanity check them, that would be great.) One isn't even merged to master yet, but I will if it doesn't break my browser by the weekend (branch npobject-bridge). I rewrote the NPRuntime bridge to be like Chromium's; the existing one leaks proxy NPObject structures everywhere[1]. I also implemented a pass-ref mode for RPC so the delayed calls mechanism can be dropped. The other reworks the RPC sync mechanism. There are a whole mess of crashes and bugs caused by interleaving. Instead of adding hacks for them one-by-one, I think it's better to obey NPAPI's assumptions[2] and sync around every event loop iteration. But it may visibly slow down browsers which do not do out-of-process plugins (i.e. everyone but Firefox 4 [3] and Chrome). I didn't notice anything, but I don't know what baseline snappiness to expect. [1] It shared the reference count globally between the two processes, so if the plugin isn't last to release a browser-owned object (i.e. almost always), then it never gets informed of the object's destruction and the NPObjectInfo and bridge NPObject stay around forever. [2] A browser with out-of-process plugins has the luxury of making some RPC calls asynchronous, and to use higher level requests when an operation requires two consecutive calls to be atomic. We don't. [3] They added out-of-process plugins in 3.6.4, but only for some plugins. Intentionally or not, it appears the check rejects an nspluginwrapper-wrapped Flash. David From stransky at redhat.com Thu Apr 21 06:45:41 2011 From: stransky at redhat.com (Martin Stransky) Date: Thu, 21 Apr 2011 08:45:41 +0200 Subject: nspluginwrapper status In-Reply-To: References: Message-ID: <4DAFD295.4010004@redhat.com> On 04/21/2011 07:21 AM, David A Benjamin wrote: > Hi Gwenole, > > Thanks for the update. > >> I saw David volunteered to become the new upstream maintainer. I have >> no objections, unless Martin wants to take the role since he has been >> working on the project for a longer time. Thanks. > > Martin, if you want to take the role instead, go for it (and feel free > pull what you want from my repo); I won't be annoyed. Less work for me > to do. :-D Otherwise, I'm happy to do it, and glad to have your > blessing, Gwenole. It felt slightly weird before as to whether I should > at least rename my fork or something... Thanks, but I'm fully focused on Firefox so I'd be happy if you can take this role. ma. From davidben at mit.edu Sat Apr 23 19:48:17 2011 From: davidben at mit.edu (David A Benjamin) Date: Sat, 23 Apr 2011 15:48:17 -0400 (EDT) Subject: [ANN] nspluginwrapper 1.3.2 Message-ID: Hi, nspluginwrapper 1.3.2, a development snapshot leading to 1.4.0, is now available. Changes from 1.3.0: * Work around lack of client-side windows in Flash * Fix race condition when NPP_Destroy was called while viewer is busy * Fix build on modern Linux platforms * Support NPAPI 0.24, in particular, Flash can now query for private browsing * Don't export any symbols but those necessary * Support XEmbeding npplayer into another application * Remove NPClass::HasMethod cache; it was incorrect * Fix initializing two wrapped plugins with the same name in the same process * Work around Qt bug that breaks npplayer when Kopete is installed * Release implicit grabs before forwarding events to fix Flash context menu hang * Work around Firefox quirk that broke windowless Flash in Firefox 4 * Bind wrapper and viewer event loops together to avoid many many race conditions * Redesign NPRuntime bridge to avoid leaking proxy objects * Incorporate release number into ident string so update works on distro patches A release tarball is available here: http://web.mit.edu/davidben/Public/nspluginwrapper/nspluginwrapper-1.3.2.tar.gz md5sum: 0f85e10f3c10b199dbdc188d62d77981 sha1sum: dad24ef907410ab12363c5d48ac66f4d9c4f5f34 The new git repository is hosted on github. https://github.com/davidben/nspluginwrapper Notes for packagers: First, this is the first release since January 2009! There are quite a few changes. In particular, the NPRuntime bridge got all but a complete rewrite, and the synchronization mechanism was reworked. I am not aware of any regressions and both fix some serious problems with the old code. That said, it could use testing, so this release is intended to be a development release. There will be a 1.4.0, so I would recommend waiting for that before updating stable releases. Second, please look over /all/ of your patches. I suspect none of them apply anymore. I have gone through all I could find and applied or rewrote the ones that make sense. I believe the only relevant patches left are wrapper management ones (src/npw-config.c). I intend to resolve that mess for 1.6.0. If anyone is carrying my patches to NPP_Destroy and delayed_calls_process (Fedora and Ubuntu?), the reworked NPRuntime bridge and sync code make them unnecessary. Finally, any distributions that have modified the wrapper management code will want to look over the update process very closely. It has almost certainly never been tested; the -u option skips updating wrappers whose version strings match the current one. Unfortunately, that version string only took into account the upstream version number, so the code has done nothing for the past two years. It now takes into account the release number in the nspluginwrapper.spec file, so remember to update it when adding patches that change the wrapper. I made notes on the situation myself, but they may be inaccurate. http://web.mit.edu/davidben/Public/nspluginwrapper-directory-patches.txt If you run into problems, please let me know. It helps to run your browser with NPW_DEBUG=1. You'll get a lot of debug spew. Regards, David Benjamin From stransky at redhat.com Wed Apr 27 10:42:26 2011 From: stransky at redhat.com (Martin Stransky) Date: Wed, 27 Apr 2011 12:42:26 +0200 Subject: [ANN] nspluginwrapper 1.3.2 In-Reply-To: References: Message-ID: <4DB7F312.7040609@redhat.com> Cool! I'll update the fedora package when I find some free time. On 04/23/2011 09:48 PM, David A Benjamin wrote: > Hi, > > nspluginwrapper 1.3.2, a development snapshot leading to 1.4.0, is now > available. > > Changes from 1.3.0: > * Work around lack of client-side windows in Flash > * Fix race condition when NPP_Destroy was called while viewer is busy > * Fix build on modern Linux platforms > * Support NPAPI 0.24, in particular, Flash can now query for private > browsing > * Don't export any symbols but those necessary > * Support XEmbeding npplayer into another application > * Remove NPClass::HasMethod cache; it was incorrect > * Fix initializing two wrapped plugins with the same name in the same > process > * Work around Qt bug that breaks npplayer when Kopete is installed > * Release implicit grabs before forwarding events to fix Flash context > menu hang > * Work around Firefox quirk that broke windowless Flash in Firefox 4 > * Bind wrapper and viewer event loops together to avoid many many race > conditions > * Redesign NPRuntime bridge to avoid leaking proxy objects > * Incorporate release number into ident string so update works on distro > patches > > A release tarball is available here: > > http://web.mit.edu/davidben/Public/nspluginwrapper/nspluginwrapper-1.3.2.tar.gz > > > md5sum: 0f85e10f3c10b199dbdc188d62d77981 > sha1sum: dad24ef907410ab12363c5d48ac66f4d9c4f5f34 > > The new git repository is hosted on github. > > https://github.com/davidben/nspluginwrapper > > Notes for packagers: > > First, this is the first release since January 2009! There are quite a > few changes. In particular, the NPRuntime bridge got all but a complete > rewrite, and the synchronization mechanism was reworked. I am not aware > of any regressions and both fix some serious problems with the old code. > That said, it could use testing, so this release is intended to be a > development release. There will be a 1.4.0, so I would recommend waiting > for that before updating stable releases. > > Second, please look over /all/ of your patches. I suspect none of them > apply anymore. I have gone through all I could find and applied or > rewrote the ones that make sense. I believe the only relevant patches > left are wrapper management ones (src/npw-config.c). I intend to resolve > that mess for 1.6.0. If anyone is carrying my patches to NPP_Destroy and > delayed_calls_process (Fedora and Ubuntu?), the reworked NPRuntime > bridge and sync code make them unnecessary. > > Finally, any distributions that have modified the wrapper management > code will want to look over the update process very closely. It has > almost certainly never been tested; the -u option skips updating > wrappers whose version strings match the current one. Unfortunately, > that version string only took into account the upstream version number, > so the code has done nothing for the past two years. It now takes into > account the release number in the nspluginwrapper.spec file, so remember > to update it when adding patches that change the wrapper. I made notes > on the situation myself, but they may be inaccurate. > > http://web.mit.edu/davidben/Public/nspluginwrapper-directory-patches.txt > > If you run into problems, please let me know. It helps to run your > browser with NPW_DEBUG=1. You'll get a lot of debug spew. > > Regards, > > David Benjamin > > _______________________________________________ > Nspluginwrapper-devel-list mailing list > Nspluginwrapper-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list >