[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Nspluginwrapper Update Status

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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]