CODEWITHSUNDEEP
macosgoogle-chromepluginsnpapi
Roman
Roman

Reputation: 53

Fail to load NPAPI plugin in Google Chrome on Mac OS X

I have been trying to get Google Chrome (6.0.401.1 dev) on Mac OS X to load an NPAPI plugin without success so far. I have been working around the npsimple example from here: http://git.webvm.net/?p=npsimple.

Using gcc on Mac and VC++ 2008 on Windows I managed to get it running on Safari and Firefox on Mac OS X and Firefox and Google Chrome on Windows, but not on Google Chrome on Mac OS X.

When trying to debug Google Chrome on Mac OS X it seemed Google Chrome was briefly dyld-loading (and immediately dyld-unloading) the plugin on startup, but without actually looking-up any symbols within the plugin or calling any of the functions. It seemed to be doing that for every plugin, though.

Also, when loading a page with the embed-tag for the plugin, Google Chrome did not seem to even dyld-load the plugin and no functions were called (not even NP_GetEntryPoints). Google Chrome also does not output any error message, it just simply does not load the plugin. I am not sure I caught everything with gdb because of Google Chrome using different processes, but I have also tried all the switches like --no-sandbox, --single-process and --plugin-startup-dialog (which incidentally does not seem to work at all on Mac OS X). I also made sure the architecture of the binary matches (i.e. 32-bit for Google Chrome).

Has anybody had similar problems before? Is there anything I am missing here, like a gcc switch when compiling or something?

Any help would be greatly appreciated.

Upvotes: 1

Views: 4607

Answers (3)

smorgan
smorgan

Reputation: 21599

I investigated this further. The problem is that npsimple's Localized.r only lists a MIME type in the ID 128 entry, and it's supposed to be a MIME type/file extension pair. WebKit and Gecko apparently tolerate the last entry not having a file extension entry, but Chromium does not.

There are two ways to get your plugin working in Chromium for Mac:

  1. The best way is to use the new Info.plist style of declaring MIME types, described in the "Registering Your Plug-in" section of Apple's plugin docs. This is supported by Firefox 3.5+, Safari, and Chrome at least; you could leave the resource as a fallback for older browsers.

  2. If you only want to use the resource, you can add an empty file extension to the MIME declaration by changing the MIME entry line in Localized.r to:

    "application/x-vnd-aplix-foo", ""

Be aware that at some browsers (including Chromium) will likely be dropping support for the old resource-based method in the foreseeable future, so I strongly encourage going with option 1.

(Arguably it's a bug in Chromium that it doesn't handle this gracefully the way the other browsers do, but since this method is deprecated, and it isn't a problem for any actually-deployed plugin I know of, it's very unlikely to be changed.)

Upvotes: 1

smorgan
smorgan

Reputation: 21599

With a couple of very specific exceptions (what MIME types are you trying to handle?) any valid NPAPI plugin should be loaded. The best thing to do would be to file a bug with as much detail as possible so that I can investigate (I work on plugin support for Google Chrome on the Mac).

Upvotes: 0

Volker Voecking
Volker Voecking

Reputation: 5583

I have just checked my plugin and it also works with the dev build you mentioned. So in principle this dev build of Google Chrome supports third party NPAPI plugins. (In the past we have seem dev builds that were only supporting Flash and Quicktime plugins.)

Some things to check:

  • Is your plugin included in the list of installed plugins that you get when you type "about:plugins" in the browser's address field?
  • Did you check the console output (run the console.app)?
    Sometimes you find valuable information in there, e.g. when loading a dylib fails...
  • It might be that something is missing from the Info.plist of the plugin bundle that Google Chrome expects.

Upvotes: 0

Related Questions