10

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

Alex K
  • 6,737
  • 9
  • 41
  • 63
  • Alex, I really hope that you're not actually evaluating the results of that XHR get as script, right? – Boris Zbarsky Jul 28 '11 at 15:03
  • 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 – Alex K Aug 01 '11 at 15:56
  • 4
    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! – Boris Zbarsky Aug 01 '11 at 17:54
  • i see, but that means even scripts from stackoverflow.com can be substituted with arbitrary ones, since they are loaded without ssl too – Alex K Aug 01 '11 at 20:04
  • 1
    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. – Boris Zbarsky Aug 01 '11 at 22:34
  • @BorisZbarsky do you consider it a security hole to inject a script into a web page using the ` – Shelby Moore III Mar 09 '13 at 16:21
  • @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"). – Boris Zbarsky Mar 11 '13 at 18:52
  • @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. – Shelby Moore III Mar 11 '13 at 19:57
  • @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. ;) – Boris Zbarsky Mar 12 '13 at 01:07

2 Answers2

8

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.

upe
  • 1,862
  • 1
  • 19
  • 33
Matthew Wilson
  • 3,861
  • 21
  • 14
  • ok this will be much better now, i'm going to try it with showInConsole and see what errors it shows – Alex K Jul 28 '11 at 12:45
  • it worked! i mean it helped :) much easier now, i replaced $.get with raw xmlhttprequest, and it's rolling now :) thanks :) – Alex K Jul 28 '11 at 13:36
  • 3
    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) – balupton Aug 07 '12 at 01:25
  • 2
    Since FF19 you can use built-in debugging tools on the browser chrome itself, see this answer for detail: http://stackoverflow.com/questions/17547364/how-debug-firefox-extension-with-chromebug/17579253#17579253 – Mike Demenok Apr 14 '14 at 08:24
3

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.

Matthew Gertner
  • 4,487
  • 2
  • 32
  • 54
  • 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.. – Alex K Jul 28 '11 at 12:45
  • Venkman isn't as stable/usable as the built in Browser Debugger now included in Firefox now. – NoBugs Apr 16 '14 at 04:49
  • Yeah this whole question is out of date now. You should post a new answer about the [Browser Toolbox](https://developer.mozilla.org/en-US/docs/Tools/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). – Matthew Gertner Apr 16 '14 at 09:55