I have a NPAPI plugin, incorporated into Chrome extension, and defined in manifest file as public. When an object tag with the plugin's mime type is inserted into background page of the extension, the plugin loads ok. When the same object tag is inserted into an arbitrary webpage using chrome.tabs.executeScript, it fails to load. If the plugin itself is placed into Plugins folder (and loaded into the browser), then the objects with the appropriate mime type are inserted into arbitrary web-pages successfully.
The question is why the plugin does not load properly into arbitrary web-page, when it is deployed within the extension and marked as public (so it is supposed to be available for any page, as far as I know).
You should use mark the plugin with "public": true in your extensions’s manifest. The plugin should show up in about:plugins.
If the plugin shows up, confirm that the MIME type and file extensions in about:plugins matches the type of the embed element being injected into the page. Also check to see if other plugins have the same MIME type. If a plugin that is listed earlier has the same MIME type, that plugin will be loaded.
If your plugin doesn’t show up, or it shows up but does not work, you’ve got more detective work to do:
You can start Chrome with the --debug-plugin-loading flag to get extra logging from the plugin infrastructure. Some of these messages look like this:
[24634:-1392008512:1466799063452984:ERROR:plugin_list.cc(358)] Loading plugin /Library/Internet Plug-Ins/Flash Player.plugin
Despite containing the word ERROR, these messages are not errors. ERROR is just the log level. Use Chromium Code Search and the files mentioned in the log (for example plugin_list.cc) to read the log messages in context. Chrome uses a multi-process architecture. So remember that the output might intersperse log messages from different processes.
If you have the source of your plugin, you put logging statements in your plugin code. For example, on OS X you could write:
NPError NP_GetEntryPoints(NPPluginFuncs *pluginFuncs) {
NSLog(#"FOO NP_GetEntryPoints");
…
and then
2012-08-20 11:22:56.799 Google Chrome Helper EH[23544:b03] FOO NP_GetEntryPoints
will show up in the log. These log statements can give you further clues about how far plugin loading is getting before it fails.
It will take some effort, but you could build Chromium from scratch and use the --plugin-launcher command line option to get source-level debugging of the plugin loader.
Posting an answer with my comment(s) as requested =]
If you install an extension with a public plugin (and everything is installed correctly) then it will show up in about:plugins. Therefore, there is something wrong with your extension/plugin installation. unfortunately, that's all I know.
about:plugins as noted in the comments will display all plugins that are public whether installed as public plugins in an extension or just installed as NPAPI plugins.
Related
I am using chromium command line switch --launch-and-load-app to start a chromium instance that shows only the app that I am developing. This is working well.
Also, I am using --register-pepper-plugins to specify a shared library containing a PPAPI plugin. This too works well, so long as --launch-and-load-app is not specified.
Unfortunately, when the two are combined, instead of the plugin being loaded, only a box appears saying "right-click to play my-plugin.so". Right-clicking does not bring up an option to load the plugin.
How can I cause the plugin to play when using --launch-and-load-app?
Create a temporary directory to act as chromium's user data directory.
Launch chromium specifying --user-data-dir=<the temp directory>, as well as the appropriate --register-pepper-plugins switch.
Visit a page containing an <embed> that loads your plugin.
Visit chrome://plugins. Find your plugin, and select 'Always allowed to run"
Save a snapshot of the temporary user data directory; it can be used as the data directory to start an instance of chromium in which your plugin will run.
I have a google chrome extension that crashes after you install it from the webstore. When installed from a local copy the extension does not crash. The crash happens when you click the tool bar icon that is added once it has been installed. The icon is supposed to load a table with URLs. Once restarted all you get is the option to recover tabs. I was hoping someone could help identify the issue of the crash or tell me how to access a crash report to see what is causing the problem.
The extension is located here:
Chrome Store App
Any help or direction will be very appreciated. Thank you
I've looked into your issue, and there are two issues here:
Your extension gets disabled, "This extension may have been corrupted."
Chrome crashes.
The latter is caused by a bug that has been fixed in Chrome 40, so I'll only focus on the first issue.
The first issue is caused by Content Verification, an (experimental) security feature in Chrome that ensures the integrity of extensions from the Chrome web store, by disabling extensions that have become corrupted crbug.com/369895. Corruption is detected by verifying the checksum of a file whenever an extension file is accessed by Chrome (for files referenced in the manifest file: at install-time; for other (embedded) files: when the file is loaded).
Unfortunately, there are some bugs in the implementation that causes extensions to be disabled in the following circumstances as well:
crbug.com/439464 - The spelling of a filename in does not match the spelling of the path. On Windows and some Mac systems, the filesystem is case-sensitive, so during development, you may not notice that the spelling of the filename is incorrect. Content verification is case-sensitive, so it will treat "icon.png" different from (uppercase) "Icon.png".
(This discrepancy in checks is unfortunate, but a good thing: if you use an incorrect spelling in the icons field, then the extension would not load on case-sensitive filesystems such as those commonly used on Linux.)
crbug.com/444085 - The paths are not resolved into a canonical form. When you use two "//" instead of "/", then Chrome will find the file, but not its corresponding checksum and disable the extension. To fix this, change "path//to/file" to "path/to/file". Fixing static paths (e.g. in HTML and CSS files) is relatively easy, but if you construct the paths dynamically, then finding the culprit becomes much harder.
To find out why your extension gets disabled, follow the instructions at crbug.com/444085#c25.
The problem was related to a broken url in one of the css files. By disabling all scripts and css we were able to find the problem.
I have successfully compiled and created npapi dll in MS based on mozilla npruntime project. Reference from: https://developer.mozilla.org/en-US/docs/Compiling_The_npruntime_Sample_Plugin_in_Visual_Studio.
Starting mozilla and open about:plugins shows the plugin. But when I open "test.html" the plugin does'nt come up.
I have tested the dll by making a separate test app, where i can access the entry point functions through
NP_INIT l_pInit= (NP_INIT)GetProcAddress(hModule, "NP_Initialize");
and i am able to step into my plugin dll function.
But with mozilla it doesn't work. Please suggest.
You can debug directly the mozilla process. Just attach to the process. However, modern browsers uses separate process for loading the third party plugins, so you will have to attach to that process. Than you can set breakpoints to loading routine (NP_GetEntryPoints, NP_Initialize) and see what is happening in there.
Also, if you have trouble with attaching to the process, you can simply show debug dialogs from your code and narrow the problem area.
UPDATE 1:
It seems like the browser does nto know that it should use the plugin. Did you specify the MIME type of hwat your plugin is for? If so, run the following script in an HTML page:
<embed type="application/x-my-extension" id="pluginId">
<script>
var plugin = document.getElementById("pluginId");
var result = plugin.myPluginMethod(); // call a method in your plugin
console.log("my plugin returned: " + result);
</script>
x-my-extensionreplace with your extension which you used in NP_GetMimeDescription. You shoudl check in about:plugins if the browser registered your plugin correctly for correct MIME type.
Sounds like there is most likely something wrong in your plugin initialization; you might try using FireBreath to create a npapi plugin, as it will be a lot less work and work on IE as well. If you don't like that idea, you could look at other npapi plugins (including FireBreath) to make sure you're doing things correctly. Add logging (of whichever type you like) to the main entrypoints and see which point it fails at.
Another trick is to go to about:config and find the plugins ipc settings and disable them; then you can attach to the main firefox process and it should hit your breakpoints if they are being called.
See the FireBreath Debugging Plugins page for other ideas.
Thanks guyz. Finally i am able to load and access the functionality of my plugin in the browser. Following are the findings:-
1. Even though my plugin's MIME type in resource file was 'application/mozilla-npruntime-scriptable-plugin'. But i need to access it from javascript embed element through 'application/x-npruntime-scriptable-plugin'. After this step the debugger started breaking on my plugin's break points.
2. The check of size of NPPluginFuncs and NPNetscapeFuncs was failing, may be because of different version of NPAPI implemented in my firefox.
At the end i got startup and thank you all for your support.
I am developing an NPAPI Firefox plugin and I have a question.
I need to load a third-party DLL (such as D:\mydll.dll), but on some computers mydll.dll is not in the system path or in c:\windows\system32 and I get loading errors.
Here is the code:
SetCurrentDirectory ("d:\");
m_hModule = LoadLibrary ("mydll.dll");
LoadLibrary returns 126. I checked with DEPENDS.EXE to view the dependent modules and everything looks fine. I do not know what the problem is.
Another problem is that I want the plug-in to work in Safari (my safari is version 5.17). I copy it into Safari's Plugins directory and it tells me it cannot find the plug-in. I want to know how to solve this.
Thank you, and please excuse my poor English.
Setting the current directory will not always work when in a plugin because you don't own the process. The command that you want is SetDllDirectory.
SetDllDirectory("D:\");
m_hModule = LoadLibrary("mydll.dll");
Of course, I don't recommend that you ever assume a DLL is in the root of the drive =] What I would do is put the DLL you need in the same directory as the plugin DLL and then you can get the path of the DLL using GetModuleFilename.
For installing, rather than putting the plugin in the plugins/ directory in the firefox (or safari) directory you should install it through the windows registry. This will make it visible for firefox, chrome, and safari.
You may want to consider using FireBreath instead of implementing the NPAPI interfaces yourself; it takes care of most of the tricky parts and leaves you free to focus on the important parts of your plugin.
I have a NPAPI API based (scriptable) plugin developed using Gecko SDK 1.9.2. This plugin works fine on FF3.6 & FF4 beta, but it fails to get detected on chrome.
Also I cannot see the plugin listed - when I do a "about:Plugins" in chrome.
I've registered the plugin as described in the "Windows Installation Using the Registry".
When monitored the chrome startup using Sysinternals tool Procmon.exe, I could find that the chrome tries to do a LoadImage on my Plugin dll, whoever it quickly unloads it.
Any ideas why this plugin is not detected by chrome will help.
It would be helpful to have an example of exactly what keys you used and where you put them; FireBreath plugins (works on all npapi and activex browsers) register themselves in the registry using that method and they work fine on chrome.
Depending on your needs, might even be worth looking into building your plugin in FireBreath instead of using npapi directly -- it's a lot less work and workarounds for various browsers have already been done.
One thing to try is to make sure you have the file name correct in the registry; Many versions of firefox just use the directory specified in the registry and search for any plugin files (this isn't documented, AFAIK, it's just my observations), whereas Chrome actually uses the path and file. It's also possible you could have a permissions issue.
The issue was that the plugin dll didn't have the resource like file description, MIME type and language set. Adding the proper resource strings fixed the issue.