Nspluginwrapper Update Status

[David A Benjamin]

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