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.
Related
I'm trying to load unpack extension using command line flag --load-extension.
I'm using one chrome profile. The syntax for query is following:
chrome --load-extension="C:\Users\someUser\Desktop\unpackExtensionFolder"
Inside unpackExtensionFolder there is manifest.JSON and all sources.
This command doesn't work on few PCs in office, but it works on the rest of them, and successfully loads the extension (Chrome version is the same on all machines - 31, extension that we are trying to load is the same).
Discovered:
Doesn't depend on chrome profiles amount
Doesn't depend on developer mode on/off
The question is why? And what could have influence on this?
The reason for this was plugin inside manifest file, seems that chrome was not able to load extension with plugin declarated in it. Works fine after removing plugin section.
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'm trying to debug some JavaScript for a Rails project and its incredibly frustrating to go line by line when the source code is compressed in the Sources developer tab.
I know this compression is done by Chrome through the body variable. What I want to know is if there is any way to stop Chrome from compressing files in source view, i.e:
\application.js?body=1 --> \application.js
Thank you for your time.
Compression is being done by Rails. Disable it in your configuration:
# config/production.rb (or whatever environment you're in)
config.assets.compress = false
You might want to investigate a new feature in Chrome called Source Maps.
Source Maps allows Chrome to map the compressed source code it receives to the uncompressed original, which in turn means that you can debug the code, even though it's been compressed.
This feature should help you get around this kind of problem without having to change the compression settings on your server.
You can read more about it here: http://blog.mascaraengine.com/news/2012/4/16/sourcemap-support-in-chrome-greatly-improves-debugging.html
I believe this feature is still in test and not yet in the final release version of Chrome. I'm sure it will arrive in due course, but for the time being you may need to install the "Canary" version of Chrome, ie the pre-release version that includes all the forthcoming features that they're still working on.
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 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.