From swt at techie.net Tue Aug 9 22:26:40 2011 From: swt at techie.net (Scott Talbert) Date: Tue, 9 Aug 2011 18:26:40 -0400 (EDT) Subject: Adobe Reader Zombies Message-ID: Hello, David, thanks for resurrecting the project. :-) I am trying to investigate an issue with the Adobe Reader plugin. It seems that the plugin will exit when it is no longer in use. After this point, the browser instance will not be able to view PDFs anymore unless you go and kill off the nspluginwrapper instance. A more concrete example (this is using Firefox 5 with Ubuntu Natty): 1) View a PDF in the browser. 2) Hit the back button. 3) Wait 30 seconds...acroread becomes a zombie. 4) Hit the forward button...you won't be able to view the PDF again. At this point, if you kill -9 the nspluginwrapper instance and reload, you can view PDFs again. Any ideas on how to investigate this further? Thanks, Scott From davidben at mit.edu Sat Aug 13 18:36:22 2011 From: davidben at mit.edu (David A Benjamin) Date: Sat, 13 Aug 2011 14:36:22 -0400 (EDT) Subject: openSUSE patches and bugs to review In-Reply-To: <1310999596.6438.20.camel@oct.suse.cz> References: <1310488888.4323.34.camel@oct.suse.cz> <1310999596.6438.20.camel@oct.suse.cz> Message-ID: Sorry this took a while to respond to. I got caught up in some other stuff. On Mon, 18 Jul 2011, Stanislav Brabec wrote: > I just tested it a bit deeper and there is a regression of the > nspluginwrapper in epiphany. > > Go to URL http://fredrik.hubbe.net/plugger/test.html and click to Adobe > PDF. > > firefox 5 + nspluginwrapper 1.4.4: focus works with and without setting > GDK_NATIVE_WINDOWS I believe Firefox sets it for you, so it's expected there isn't a difference here. > epiphany 2.30.6 + nspluginwrapper 1.3.0: focus does not work with and > without GDK_NATIVE_WINDOWS > > epiphany 2.30.6 + nspluginwrapper 1.4.4: focus does not work with and > without GDK_NATIVE_WINDOWS, browser crashes on quit > > epiphany (old version) + nspluginwrapper (old version): focus works > (maybe it is broken since migration to WebKit) Is "(old version)" here 1.3.0? Yeah, I would expect it to have been caused by something in WebKitGtk, especially since Gecko seems to work fine. I can also confirm the focus issues, and that GDK_NATIVE_WINDOWS has no effect. Not sure what could be causing that. Sometime I'll see about getting a 32-bit Epiphany/WebKitGtk and we can at least see if this is caused by nspluginwrapper. (Too bad multiarch on Linux is so painful...) I don't get the crash though. Could you perhaps run with NPW_DEBUG=1 or get a stack trace? (I'm on Epiphany 2.30.2-1ubuntu7 and WebKitGtk 1.2.5-0ubuntu0.10.10.1.) Perhaps it's something to do with having multiple wrapped plugins on your system? WebKitGtk seems to have this habit of initializing plugins more than necessary. On Linux, just to determine what MIME types a plugin handles, you need to actually load it in and call a function in it (specifically NP_GetMIMEDescription). Most browsers just call that directly without calling NP_Initialize first, but WebKitGtk seems to NP_Initialize every plugin as well as NP_GetMIMEDescription. For nspluginwrapper plugins, this means that, as soon as Epiphany encounters a page with any plugin, it starts up viewer processes for every nspluginwrapper-wrapped plugin on the system. (I believe this was the impetus for my fixing a crash when multiple copies of the same plugin got loaded at once.) It's possible this is what you're hitting, but I'm just speculating. > So I cannot answer, whether epiphany + acroread need GDK_NATIVE_WINDOWS > > nppdf launches acroread. I am not sure whether it inherits environment > variables. It does. But when acroread is launched as a normal app, it does not get this setting. Barring really strange plugin-related effects, I expect them to have dealt with any such problems as part of making the normal app work. Dunno. > I asked my colleague. There were some bugs related to GDK native windows > implementation in Eclipse. But we probably don't need to handle this in > nspluuginwrapper, because Sun now release 64bit plugins. Mmm. Well, I went ahead and applied the patch anyway. If this isn't isolated to Flash, I guess we may as well workaround this uniformly. Would be good to get the setting into WebKitGtk though. > By the way, here is my test suite for nspluginwrapper: > > For all supported browser do following: > > Adobe Flash: > Go to http://www.addictinggames.com/bloxors.html > Start game. > Game must react correctly to arrows. > > Adobe Reader: > Go to http://fredrik.hubbe.net/plugger/test.html > Click to Adobe PDF > Click to the document > Cursor must react correctly to arrows. Thanks! I'll keep these in mind during future testing. David