How to debug Firefox extension

Question

I've been into Firefox extension development recently, and ran into some issues:

So, in browser.xul i defined these lines:

<overlay id="sample" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
    <script src="jquery.js" />
    <script src="global.js" />
</overlay>

So, in global.js i have access to all jQuery stuff, and trying to load a simple script there:

var inner = null;
var o = function () {
    var prefManager = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefBranch);
    return {
        init : function () {
            alert('here loading inner..');
            $.get('http://www.example.com/script.js', function(d) {
                alert('loaded inner script!');
                inner = d;
                gBrowser.addEventListener("load", function () {
                    alert('onload');
                }, false);
            }).error(function(e) { alert('error loading inner..'); setTimeout(o.init,1000); });
            $(this).ajaxError(function() { alert('ajaxError'); });
        }
    }
}
window.addEventListener("load", o.init, false);

But nor i receive a "loaded inner script", nor a "error loading inner" alert.. And i don't see the error console to log any errors from the extension... I assume the $.get is silently failing due to some restrictions maybe, but is there a proper way to debug the errors normally? The error console is silent for the extension, it only shows errors from the web pages

Hiller

Alex, I really hope that you're not actually evaluating the results of that XHR get as script, right? – Trough

yes, but mainly because the addon is made to be "autoupdatable" - i know it's bad, i never do this in everyday life, but in this particular project, i just had to – Hiller

The point is that if you do that, then you're introducing a security hole into the browser. Anyone using such a browser on an untrusted wifi connection, for example, allows the wifi router to inject arbitrary script into chrome. At least use SSL here! – Trough

i see, but that means even scripts from stackoverflow.com can be substituted with arbitrary ones, since they are loaded without ssl too – Hiller

Yes, and presumably the stackoverflow.com maintainers don't care if random wifi operators can run random script pretending to be stackoverflow... or even impersonating the whole site. If they did, they would be running their site on SSL. – Trough

@BorisZbarsky do you consider it a security hole to inject a script into a web page using the <script> tag (regardless if done from an extension or even the HTML of the page itself) that does not use SSL for the script's url? Since such an example runs inside the web page sandbox, presumably the browser has to guard against rogue web pages. Of course the browser can't prevent phishing due to script injection into the web page sandbox. Phishing and script injection can be done from the HTML too, so are you implying all urls should be https? – Dallis

@ShelbyMooreIII Injecting a non-SSL script is an obvious XSS hazard on the part of the page. It's not a security hole for the browser per se, unless you do it for SSL pages, in which case it's a security hole in that you're introducing XSS bugs into sites. But my point was that injecting such a script into the browser chrome is a critical security vulnerability (defined as "allows attacker to run arbitrary binary code on the victim's computer"). – Trough

@BorisZbarsky thanks I wanted to confirm that if an extension is injecting a non-SSL script into a non-SSL page, that is not a threat to violate the browser's sandbox for web pages (notwithstanding any bugs in that sandbox). Thus I assume Mozilla would not frown on this. I asked because my extension currently does that, because that 3rd party page already loads non-SSL scripts, so loading mine from SSL wouldn't add any security. – Dallis

@ShelbyMooreIII Yeah, injecting non-SSL stuff into a non-SSL page isn't really going to make it any worse; the door is already wide open. ;) – Trough

Answer 1

If you look at the article Setting up an extension development environment it suggests setting up some preferences, including javascript.options.showInConsole = true, which logs errors in chrome files to the Error Console.

Megalomania

ok this will be much better now, i'm going to try it with showInConsole and see what errors it shows – Hiller

it worked! i mean it helped :) much easier now, i replaced $.get with raw xmlhttprequest, and it's rolling now :) thanks :) – Hiller

Is there any way to get debugging with breakpoints? An error console is as useful as a mule on drugs. (but yes, still better than nothing) – Namecalling

Since FF19 you can use built-in debugging tools on the browser chrome itself, see this answer for detail: #17547864 – Agonistic

Answer 2

In general it can be problematic using JQuery in a XUL page since it assumes that the document is an HTML DOM rather than an XML DOM and that the window is a HTML window rather than a XUL window. If I were you I'd use the subscript loader for this. To debug you can use Venkman although it is a bit flakey and I often resort to just dump() statements to the console instead.

Update: see my comment below about the Browser Toolbox.

Neva

it seems the loadSubScript can't load external urls ("The URL pointing to the script to load. It must be a local chrome:, resource: or file: URL"), while i need to get it from example.com/myscript.js.. – Hiller

Venkman isn't as stable/usable as the built in Browser Debugger now included in Firefox now. – Chelseachelsey

Yeah this whole question is out of date now. You should post a new answer about the Browser Toolbox (formerly Browser Debugger) which I agree is a great new innovation (it's been around for less than a year and is getting stabler with every release). – Neva