Bug 29250 – Add nspluginwrapper plugins dir

• Component: WebKitGTK
• Status: RESOLVED WONTFIX

[Bastien Nocera]

Created attachment 39560 [details]
webkitgtk 1.14 patch

This will allow nspluginwrapper to take over the plugins, so:
- plugins crashing don't take down the browser
- 64-bit builds can load 32-bit plugins

You'll need to run mozilla-plugin-config (from nspluginwrapper) by hand until the browsers do that for you.

[Jan Alonzo]

Is this Linux only? If so it needs to be ifdef'd.

Also the patch needs a Changelog and marked as r? if it's for review. Please see http://webkit.org/coding/contributing.html for more info on contributing.

[Bastien Nocera]

(In reply to comment #1)
> Is this Linux only? If so it needs to be ifdef'd.

Not Linux only, but X11 backends only. What macro do you enable for those targets?

> Also the patch needs a Changelog and marked as r? if it's for review. Please
> see http://webkit.org/coding/contributing.html for more info on contributing.

Ta.

[Bastien Nocera]

Created attachment 39818 [details]
updated patch

1.3GB of data to download for a 3 line-patch...

[Eric Seidel (no email)]

Comment on attachment 39818 [details]
updated patch

Your ChangeLog has tabs.  That will fail to land due to our pre-commit hook which looks for tabs.  Yes, we definitely should warn about this earlier than during review.  (bug 29509).

Otherwise it looks sane enough to me.  I'll CC the linux chromium folks that they might give more than just a rubber stamp (As they actually know something about plugins on linux and I don't). :)

r- for the ChangeLog problem.  I would have r+'d this and you could fix it on landing if you were a committer.

[Evan Martin]

Where do these paths come from?  At least on my machine, nspluginwrapper appears to install its wrapped plugins directly into /usr/lib/mozilla/plugins etc.

[Bastien Nocera]

(In reply to comment #5)
> Where do these paths come from?  At least on my machine, nspluginwrapper
> appears to install its wrapped plugins directly into /usr/lib/mozilla/plugins
> etc.

Which platform are you running this on? You need a 64-bit browser, and both the 32-bit and 64-bit versions of nspluginwrapper installed to see those.

[Antoine Labour]

I'm surprised this is needed. I don't think Mozilla looks for these paths, I think it's nspluginwrapper's responsibility to put the wrapped plugins into the right paths (or add symbolic links). That's how distributions (e.g. Ubuntu) do it.

[Bastien Nocera]

(In reply to comment #7)
> I'm surprised this is needed. I don't think Mozilla looks for these paths, I
> think it's nspluginwrapper's responsibility to put the wrapped plugins into the
> right paths (or add symbolic links). That's how distributions (e.g. Ubuntu) do
> it.

Right. Those paths are actually used by "mozilla-plugin-config", what seems to be a Fedora/Red Hat specific helper for nspluginwrapper, which will set up plugins to be wrapped automatically.

Given that the similar patch for Firefox is in the startup script, and not upstream, I'll close this bug.

The patch is already part of the WebKit-GTK build for Fedora, and epiphany has been patched to call "mozilla-plugin-config".