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.
Related
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.
We are trying to distribute a basic HTML file with some links to a PDF document in a USB drive for advertising purposes. The idea is that an autorun opens up this HTML in the default browser. However, this might not be a good idea since it would look very amateur-ish and we will have to rely on the default browser's technology (which unfortunately has a good chance on being IE6/7!)
We've explored a few alternatives, but we can't find one that really fits what we are trying to achieve:
Mozilla Prism
Altough it seems like it's designed with offline web apps in mind, the executable creates files in the user's AppData directory and it's hard to configure the default paths. Also, Firefox doesn't have a default PDF viewer, so we will have to depend on the user's default PDF viewer (which might be Adobe Reader)
Mozilla Chromeless
Since Prism is inactive, the idea is still developing with Chromeless, which allows the developer to create the browser interface with basic HTML/JS/CSS. The main issue here is that somehow the build isn't loading HTML, all that's showing is a gray iframe. I'm not sure if it's just me, because there's nothing on the issues page.
Portable App
We could throw in the portable version of Firefox or Chrome and customize the XUL for Firefox or open Chrome in app mode.
Firefox's advantage is that it kind of supports relative paths (resource://), but it doesn't have a built-in PDF viewer. Chrome has a very good and lightweight PDF viewer and the built-in app mode is a very useful feature for us, but I can't find how to open a local path without the usual absolute path (file:///C:/) since we don't know what's the drive's letter.
Has anyone figure out how to handle this kind of issues? Thanks.
This has been asked three years ago, but it's unanswered, listed high in Google, and I stumbled over the exact same problem and can imagine that many others that seek to ship portable web apps that can be run locally and with a minimum of dependencies will encounter this issue, too.
The solution I am now going with is the node-webkit.
You can treat it like a portable version of chrome, however it excepts a relative path to your app's entry point, is about 40 MB smaller, and much more customizable than the --app mode of chrome (which isn't customizable at all if I remember correctly).
Github & Download:
https://github.com/rogerwang/node-webkit#downloads
An extensive guide:
http://thejackalofjavascript.com/getting-started-with-node-webkit-apps/
My usage suggestion for Windows:
First create an app package as explained in the guide linked above
For the node-wekit to load with your app, you need to start it like this:
nw.exe app.package
Where nw.exe is in the root of the zipped folder you downloaded and app.package is a zip file (can have any name) that contains your app data and package.json.
To do this silently, you can use a BAT file containing the (amended) call above and a VBS file containing something like this:
CreateObject("Wscript.Shell").Run "cmd /c launchNW.bat", 0, true
launchNW.bat being the name of your BAT file. Now run the VBS file; a window containing your web app should pop up without the command window appearing with it.
Finish reading the linked guide to learn more about customization options to do things like hiding the browser UI etc.
Okay, so I'm a student programmer in my college's IT department, and I'm doing browser compatibility for a web form my boss wrote. I need the user to be able to open a local file from a shared drive with a single click.
The problem is that Firefox and Chrome don't allow that for security reasons. Thus, I'm trying to write a custom protocol of my own to open an address in Internet Explorer regardless of the browser being used.
Can anyone help me with this? I'd also be willing to try an alternative solution to the problem.
The below worked for me, is this what you mean?
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo]
#="URL: foo Protocol"
"URL Protocol"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\DefaultIcon]
#="C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell\open\command]
#="C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe \"%1\""
Just to note, I'm running Win7Pro, so you may have to move around file path(s) to conform to your environment.
And if that doesn't work, create a proxy between the protocol and the browser, pass the argument(s) from foo:// to that, parse what's necessary, then hand it off to IE using start iexplorer.exe "args".
I'm unsure whether I understand your question, if it is how do I open local files using chrome/firefox, this is your anwser:
First a disclaimer, I have never done this and cannot vouch for the accuracy of my response
IE
Microsoft's security model is pretty fail so you can go right ahead and open these files
FireFox
Some quick googling found that Firefox can do this after either editing prefs.js as outlined here or installing an addon called LocalLink
Chrome
Practically impossible due to its security, until now when locallink was ported to chrome.
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.