I am very new to writing plugins for firefox. I am writing a plugin to intercept a URL protocol (I got it here: http://www.nexgenmedia.net/docs/protocol/) inside the plugin and then call some user loaded Jscript functions to pass data.
My question is, How can i call a user script or a greasemonkey script from within a firefox plugin when the plugin is running.
This is generally a very bad idea to run arbitrary code from an extension. The extension code is executed in privileged mode with access to XPCOM (and thus the whole system).
If you really DO want to execute external JS, the best way is Components.utils.Sandbox I suppose. Other options are nsISubscriptLoader or Components.utils.import.
Also, afaik such extensions won't pass security check at Mozilla Addons and won't be accepted there as a result.
Related
I have a Selenium Java library that includes a JavaScript "glue" library that enables JavaScript functions to throw serialized Java exceptions. This enables much more natural handling of exceptional conditions without a lot of boilerplate.
Prior to executing a script that may want to throw an exception, I inject this library into the target page in a closure via executeScript. Upon return, the functions defined in the closure persist on the page, available for scripts that execute afterward to use for throwing exceptions.
This technique works as expected on HtmlUnit, Chrome, and Edge. However, the enclosed functions don't persist when I use this technique on Firefox. If I paste the closure into the multi-line editor in Developer Tools, the functions are retained, but this isn't a strategy I can use in Selenium Java automation.
Is there a different method I can use to add functions to a web page on-the-fly? Is there a Firefox setting that might allow the technique I'm using to work as expected?
The source for the script I'm using now can be found here: https://github.com/sbabcoc/Selenium-Foundation/blob/master/src/main/resources/javaGlueLib.js
As indicated in the comments, the structure and "namespace" functionality of the closure was obtained from here: https://github.com/jweir/namespace/blob/master/namespace.js
I found my answer. I always knew that my original implementation was drawing outside the lines, and Firefox won't let me get away with that.
The solution is to create a script element, set the [textContent] of this element to my original script source, and attach this new script node to the head element of my target page.
var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.textContent = arguments[0];
head.appendChild(script);
This maybe a limitation of Firefox itself. But I am only guessing.
Have you tried a Man in the Middle proxy? such as https://mitmproxy.org
You will need to be in an environment where your test browsers can trust the MITM certificate. Then you can configure the MITM server to inject whatever you want into the requests.
The advantage of a MITM is will be browser agnostic.
Another option might be to use GreaseMonkey for Firefox.
https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
I have a long time stick with Conkeror as my default web browser and get used to configuring/adding new features to my browser using js code with all the XUL Api through the .conkerorrc file. I'm migrating to Firefox since it has better support and is actively maintained by Mozilla. However, one of the feature that I've been missing so much is the dot file, which I can easily configure anything that I like, back up all of them through git and eval the code directly (using Mozrepl) while I'm coding to see the result.
Is there any way that I can inject/execute a sciprt on Firefox startup, for example ~/.firefox/index.js?
There is no functionality in stock Firefox to execute JavaScript code supplied by the user at startup. Functionality like this has been something that has been requested of Firefox since 2006-04-02.
It is trivial to write an add-on in any of the different Firefox add-on types (XUL/Overlay, Restartless/Bootstrap, Add-on SDK, or WebExtensions) which would run whatever JavaScript you desire upon Firefox startup. This could be done to either run code that was included in the add-on (simple), or that runs the JavaScript contained in a file that is loaded from a location external to the add-on (more complex). Which add-on type you used to implemented this would impact which interfaces you had available within the code you write. One drawback of writing your own extension which runs code included in the add-on is that in order to use it with a release, or beta version of Firefox is that you would need to have it signed by Mozilla. While this is a quick and easy process, it does add some additional overhead to the development/test cycle.
You have not specified any of the firefox-addon tags in your question. In addition, you have not described the functionality you desire, except as generalities. It also does not appear to be the intent of your question to ask how you would implement such an add-on. Given those and the fact that there are already multiple add-ons that implement the functionality of running arbitrary JavaScript (including XUL) code supplied by the user, I am not going to supply code here which performs this function.
However, if you are interested in using an already existing add-on, here are a few options:
userChromeJS: This extension was derived from the code originally provided as an example of how to implement the functionality requested in bug 332529. Its first feature listed is: "Complete chrome customization is possible by running custom javascript code or overlaying chrome with .xul overlays." This is an Overlay based add-on with which you can use XUL. This sounds like the functionality what you are interested in obtaining.
uc: "A userChromeJS clone with built-in subscript/overlay loader capability."
Greasemonkey: "Customize the way a web page displays or behaves, by using small bits of JavaScript." This is a commonly used add-on which permits writing more complex JavaScript code. The code is executed in a sandbox, not in the scope of an extension. This is done for security reasons.
Custom Style Script (Inject desired CSS or JS): "Add Custom JavaScript Codes or Styles (CSS) to an specific page or all pages."
Our clients use RDP sessions created by clicking a button on our site which uses the old MSRDP.cab file called in a webpage. We also utilize Virtual channels using a custom dll. Both our dll and the MSRDP.ocx are loaded through the object tag and cab files using VBScript.
As you might know, the orginal RDP connection script was written in VBScript. Apparently the ActiveX control will only work if called using VBScript. That has been working for over a decade. However the newer IE browsers and virtually all of the other browsers do not support VBScript.
I realize that I can call the new RDP program mstsc.exe from Javascript for a straight connection. However, we also pass information to the old ocx like the plugin parameters in Advancedsettings which include our dll that uses virtual channels. In addition, we pass the domain and username.
Maybe I'm searching in all the wrong places but I'm turning up no answers in trying to find how to run this ocx in javascript or another solution that would work. I'm thinking there has to be a replacement out there that I'm overlooking.
We are able to force our clients to use IE so we are currently having our clients with IE versions over 10 to use compatibility mode. However I'm sure at some point this may no longer work.
Has anyone out there had a similar problem that you have found a solution for? Any ideas or suggestions would be appreciated. Thanks!
You mentioned it yourself that in the future, your ActiveX may no longer work and supported so I strongly believe that you should invest your time in re-writing your app using a more modern approach instead.
Here's a link to a solution where it is using Jquery and ASP.NET to open an RDP connection:
Open RDP Connection window using jquery - client side
In a browser you can determine what files are loaded when a website loads and you can even view the timeline.
But is there any way to determine what javascript calls are being made once the script loads for a website?(in firefox or chrome or any software package)
Hope you got my question
(Because that would be useful for debugging logical javascript errors and others I suppose)
I use Chrome's Developer Tools for this:
Check the click box, and then click on the element on the page you want to find the handler for. If you are using jQuery (or similar library), you may have to step through their code before you get to yours.
Taken from: How do I find out what javascript function is being called by an object's onclick event?
Typically I just use logging in FireBug personally (which despite my desperate approach to avoid Chrome, is turning out to force me to adopt it with built-in developer tools).
I'm trying to write a Firefox extension that intercepts a certain HTTP request and return static content without the request making it to the actual server (similar to AdBlock).
I've looked up the tutorials and I've got a basic file layout. I've also worked out that I need to use the nsITraceableChannel API and add an observer to do what I want and I have example code for that.
Problem is, where do I actually put this code? And when is my extension actually loaded and executed? Is it running constantly and asynchronously in the background or is it loaded per page view?
The documentation doesn't seem very clear on this. This extension won't need a GUI so I don't need the layouting XUL files (or do I?). I tried writing some XPCOM (I don't think I did it right though) component, registered it in chrome.manifest but it doesn't seem to run.
Can anyone explain exactly how the Firefox extensions work and where should I put my actual JavaScript code to monitor requests? Or have I got the whole idea of what an extension is wrong? Is there a difference between add-ons, extensions and plugins?
Concerning the difference between add-ons, extensions and plugins you should look at this answer. But in general, you seem to have the correct idea.
The problem is, there are currently three very different types of extensions:
Classic extensions (not restartless): these will typically overlay the browser window and run code from this overlay. Since there is one overlay per window, there will be as many code instances as browser windows. However, classic extensions can also register an XPCOM component (via chrome.manifest as of Gecko 2.0). This component will be loaded on first use and stay around for the entire browsing session. You probably want your component to load when the browser starts, for this you should register it in the profile-after-change category and implement nsIObserver.
Restartless extensions, also called bootstrapped extensions: these cannot register overlays which makes working with the browser UI somewhat more complicated. Instead they have a bootstrap.js script that will load when the extension is activated, this context will stay around in background until the browser is shut down or the extension is disabled. You can have XPCOM components in restartless extensions as well but you will have to register them manually (via nsIComponentRegistrar.registerFactory() and nsICategoryManager.addCategoryEntry()). You will also have to take care of unregistering the component if the extension is shut down. This is unnecessary if you merely need to add an observer, nsIObserverService will take any object implementing nsIObserver, not only one that has been registered as an XPCOM component. The big downside is: most MDN examples are about classic extensions and don't explain how you would do things in a restartless extension.
Extensions based on the Add-on SDK: these are based on a framework that produces restartless extensions. The Add-on SDK has its own API which is very different from what you usually do in Firefox extension - but it is simple, and it mostly takes care of shutting down the extension so that you don't have to do it manually. Extensions here consist of a number of modules, with main.js loading automatically and being able to load additional modules as necessary. Once loaded, each module stays around for as long as the extension is active. They run sandboxed but you can still leave the sandbox and access XPCOM directly. However, you would probably use the internal observer-service module instead.