From stransky at redhat.com Sun Jul 5 04:58:24 2009 From: stransky at redhat.com (Martin Stransky) Date: Sun, 05 Jul 2009 06:58:24 +0200 Subject: Patch to fix bug where arrays of NPIdentifiers were marshalled incorrectly In-Reply-To: <5323d74a0906261645r74c7ca0ib31fef6d7955663b@mail.gmail.com> References: <5323d74a0906261645r74c7ca0ib31fef6d7955663b@mail.gmail.com> Message-ID: <4A5032F0.6070503@redhat.com> Cool, thanks! I'm just back from PTO and I'll check it during next week. On 06/27/2009 01:45 AM, Tristan Schmelcher wrote: > Hello, > > I'm a developer on Google's open-source O3D plugin project for doing > hardware-accelerated 3D rendering in web browsers ( > http://code.google.com/apis/o3d/). O3D is 32-bit only due to a dependency on > Google's V8 JavaScript JIT engine, so I've been working on compatibility > with nspluginwrapper so that we can support 64-bit Linux. Along the way I > discovered that one of the issues was a bug in nspluginwrapper's marshalling > of arrays of NPIdentifiers. A patch with the fix is attached. Apply with > "patch -p0< FILENAME". > > The bug exists in versions 1.2.0 and later. The issue is that NPIdentifiers > are passed to the do_send_NPIdentifier function by _value_, not by pointer, > which is how other parameters are passed to their marshallers. This is fine > when calling rpc_method_send_reply, but it results in a bug when marshalling > arrays of NPIdentifiers, because the array marshalling code in > rpc_message_send_args passes the individual elements by passing a pointer to > their position in the array. This resulted in do_send_NPIdentifier > interpreting the address of the NPIdentifier as the NPIdentifier itself. As > a result, nspluginwrapper's implementation of NPN_GetStringIdentifiers was > broken, because the NPIdentifier values that it returned to the plugin were > mapped to garbage addresses in the browser. > > My fix is to change NPIdentifiers to be passed by pointer. With this fix, > nspluginwrapper can successfully run O3D plugins built from our SVN trunk at > revision 19440 or later. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nspluginwrapper-devel-list mailing list > Nspluginwrapper-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list From stransky at redhat.com Sun Jul 5 05:10:11 2009 From: stransky at redhat.com (Martin Stransky) Date: Sun, 05 Jul 2009 07:10:11 +0200 Subject: Pausing plugins when not visible? In-Reply-To: <3a0a97520903262249y682b6c8alf1ea138959a8de07@mail.gmail.com> References: <3a0a97520903262249y682b6c8alf1ea138959a8de07@mail.gmail.com> Message-ID: <4A5035B3.6020608@redhat.com> It looks like wonderful idea...I see that flash adds take about 80% cpu on some sites. But what content could be handled this way? I see that many of those "cpu eating" applets are adds and you can remove them by AddBlock (and AFAIK there should be some other "flash blocking" extension available). On 03/27/2009 06:49 AM, Luke Hutchison wrote: > Adobe Flash Player for Linux is unbearably slow once you have a lot of > windows open containing Flash content, to the point that Firefox can become > almost unusable. Using nspluginwrapper seems to help a bit (because it runs > the plugins in separate processes?) but is not a complete cure as the CPU is > still pegged. As an example, try opening several content-heavy myspace > pages at once in different tabs. > > Is it possible to add a setting to nspluginwrapper that will simply freeze > plugins whenever their display area is not visible on screen? > > That would obviously cause some sites that you want to have running in the > background, like pandora.com, to stop working -- but maybe there could be a > whitelist of these? > > This would be a strong reason for many people to start using > nspluginwrapper, as the Web is replete with complaints of slow Flash > performance under Linux. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nspluginwrapper-devel-list mailing list > Nspluginwrapper-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list From andrew-nspluginwrapper at pileofstuff.org Fri Jul 10 13:51:34 2009 From: andrew-nspluginwrapper at pileofstuff.org (Andrew Sayers) Date: Fri, 10 Jul 2009 14:51:34 +0100 Subject: Fullscreen Flash and screensavers Message-ID: <4A574766.7060401@pileofstuff.org> Flash currently doesn't disable the screensaver when displayed fullscreen. This is rightfully a bug in Flash, but Adobe don't seem to be giving it much priority[1]. This is a significant irritant, and there's evidence that users are working around it on their own[2]. I'm interested in fixing this problem, and nspluginwrapper seems like the least-worst place to put the fix. Suggestions for a less-worse place are of course welcome :) The attached patch adds a program called npsaver.bin, which disables the GNOME or KDE screensaver when it detects that npviewer.bin is fullscreen and on the top of the stack. It does this by monitoring X Window events. I've implemented this as a separate program because it needs to be a 64-bit executable on 64-bit architectures in order to link against libdbus-1, whereas the rest of nspluginwrapper is always i386. This patch makes nspluginwrapper depend on the libdbus-1 development files. The patch directly modifies the "configure" script to check for that dependency - I think that's naughty, but I can't find the m4 script that automatically generates "configure". I've modified src/npw-viewer.sh to start and kill npsaver.bin when the script starts and finishes, but src/npw-viewer.sh isn't used on 32-bit architectures, so I'm not sure how to proceed. Would it be better to make this a thread or child process in the i386 case? I'd be happy to submit another patch if someone could point me in the right direction. This patch was originally created as a branch of Ubuntu's nspluginwrapper code[3], then altered for SVN (revision 942). - Andrew Sayers [1]http://bugs.adobe.com/jira/browse/FP-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel [2]http://ubuntuforums.org/showthread.php?t=1090393 [3]https://code.launchpad.net/~andrew-bugs-launchpad-net/nspluginwrapper/flashsaver -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-flash-with-screensavers.diff Type: text/x-diff Size: 17206 bytes Desc: not available URL: From stransky at redhat.com Wed Jul 15 14:49:37 2009 From: stransky at redhat.com (Martin Stransky) Date: Wed, 15 Jul 2009 16:49:37 +0200 Subject: Patch to fix bug where arrays of NPIdentifiers were marshalled incorrectly In-Reply-To: <5323d74a0906261645r74c7ca0ib31fef6d7955663b@mail.gmail.com> References: <5323d74a0906261645r74c7ca0ib31fef6d7955663b@mail.gmail.com> Message-ID: <4A5DEC81.8070509@redhat.com> Filled as https://bugzilla.redhat.com/show_bug.cgi?id=511897 and added to Fedora 12 (rawhide) package. On 06/27/2009 01:45 AM, Tristan Schmelcher wrote: > Hello, > > I'm a developer on Google's open-source O3D plugin project for doing > hardware-accelerated 3D rendering in web browsers ( > http://code.google.com/apis/o3d/). O3D is 32-bit only due to a dependency on > Google's V8 JavaScript JIT engine, so I've been working on compatibility > with nspluginwrapper so that we can support 64-bit Linux. Along the way I > discovered that one of the issues was a bug in nspluginwrapper's marshalling > of arrays of NPIdentifiers. A patch with the fix is attached. Apply with > "patch -p0< FILENAME". > > The bug exists in versions 1.2.0 and later. The issue is that NPIdentifiers > are passed to the do_send_NPIdentifier function by _value_, not by pointer, > which is how other parameters are passed to their marshallers. This is fine > when calling rpc_method_send_reply, but it results in a bug when marshalling > arrays of NPIdentifiers, because the array marshalling code in > rpc_message_send_args passes the individual elements by passing a pointer to > their position in the array. This resulted in do_send_NPIdentifier > interpreting the address of the NPIdentifier as the NPIdentifier itself. As > a result, nspluginwrapper's implementation of NPN_GetStringIdentifiers was > broken, because the NPIdentifier values that it returned to the plugin were > mapped to garbage addresses in the browser. > > My fix is to change NPIdentifiers to be passed by pointer. With this fix, > nspluginwrapper can successfully run O3D plugins built from our SVN trunk at > revision 19440 or later. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nspluginwrapper-devel-list mailing list > Nspluginwrapper-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list From stransky at redhat.com Wed Jul 15 14:54:25 2009 From: stransky at redhat.com (Martin Stransky) Date: Wed, 15 Jul 2009 16:54:25 +0200 Subject: Pausing plugins when not visible? In-Reply-To: <3a0a97520903262249y682b6c8alf1ea138959a8de07@mail.gmail.com> References: <3a0a97520903262249y682b6c8alf1ea138959a8de07@mail.gmail.com> Message-ID: <4A5DEDA1.200@redhat.com> Filled as https://bugzilla.redhat.com/show_bug.cgi?id=511898 ma. On 03/27/2009 06:49 AM, Luke Hutchison wrote: > Adobe Flash Player for Linux is unbearably slow once you have a lot of > windows open containing Flash content, to the point that Firefox can become > almost unusable. Using nspluginwrapper seems to help a bit (because it runs > the plugins in separate processes?) but is not a complete cure as the CPU is > still pegged. As an example, try opening several content-heavy myspace > pages at once in different tabs. > > Is it possible to add a setting to nspluginwrapper that will simply freeze > plugins whenever their display area is not visible on screen? > > That would obviously cause some sites that you want to have running in the > background, like pandora.com, to stop working -- but maybe there could be a > whitelist of these? > > This would be a strong reason for many people to start using > nspluginwrapper, as the Web is replete with complaints of slow Flash > performance under Linux. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Nspluginwrapper-devel-list mailing list > Nspluginwrapper-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/nspluginwrapper-devel-list