How to get a stack trace for “Invalid chrome URI”

Question

I'm debugging a XUL-based Firefox extension which has been broken by Firefox 46 release.

When I run the extension, the Browser console shows:

Invalid chrome URI: /

with neither line numbers nor stack trace.

On Web forums, I've read that ChromeBug could be used for that. Then, I've tried the latest stable version of ChromeBug (1.7.2) but it hasn't been updated since oct. 2014, and seems to be incompatible with recent Firefox versions.

Because the extension is an "old-style" one, I cannot use the Add-on debugger, therefore I used the Browser toolbox, but it doesn't display the exception.

Considering the number of lines of the extension, wandering around in the code is not an option. Any idea how I could get a stack trace?

Answer 1

When getting this type of error in the Browser Console where you are given very little information as to what is causing the error it is likely that the error is not in JavaScript, and probably not even inside your code. In such cases, it is impossible to obtain a JavaScript stack trace because it just doesn't exist.

Such a thing is usually caused by issues in XUL or HTML used in a popup or tab that is opened. Your add-on opens a tab with the contents of chrome://restclient/content/restclient.html. Substituting for that file an HTML document with no content makes the error go away.

Using a binary search of the contents of that file (comment-out/delete progressive half portions of the file at a time and test to see if the errors still exist) to A) confirm that the error is there and B) what is causing the error, results in determining that the following line is causing the error to show up in the Browser Console (line 197):

<input class="span5" style="width:-moz-calc(100% - 1em) !important;" type="password" name="password" autocomplete="on" placeholder="Password">

A little more testing shows that the problem goes away when type is not password. Copying the original HTML document to a place where I can access it easily with a file: URL, results in no such error in the browser console when the document is opened.

Thus, the conclusion is that it is a bug in Mozilla's code for <input type="password"> when loaded from a chrome: URI.

Finding an invalid chrome: URI in code without a stack trace:
If the problem was not found in the HTML or XUL files, it would be necessary to look through the chrome: URIs which are used in your add-on to find what might be the cause.

chrome: URIs have some properties we can take advantage of in tracking down such an issue:

• chrome: URIs are usually static.
• chrome: URIs usually come in the format chrome:\\packageName\{content,skin,locale}
• Your chrome.manifest file defines what chrome: URIs can be valid for your add-on/package.
• Other chrome.manifest files define what chrome: URIs can be valid outside of your add-on/package.

So first look at your chrome.manifest file:

content   restclient                content/
resource  restclient                ./

overlay chrome://browser/content/browser.xul chrome://restclient/content/overlay.xul
overlay chrome://navigator/content/navigator.xul    chrome://restclient/content/overlay.xul
style chrome://global/content/customizeToolbar.xul chrome://restclient/content/css/overlay.css

This tells us that in your package, the only valid internal chrome: URIs will be in the format chrome://restclient/content/ and will refer to the content directory within the root directory of your add-on.

So, we now look for all the chrome: URIs used in your add-on. To do that, the command line of grep -nri chrome: * is an easy way to do so. grep is available as a standard utility program under multiple operating systems. In Windows, I usually get it from Cygwin. From that command we get:

chrome.manifest:4:overlay chrome://browser/content/browser.xul chrome://restclient/content/overlay.xul
chrome.manifest:5:overlay       chrome://navigator/content/navigator.xul        chrome://restclient/content/overlay.xul
chrome.manifest:6:style chrome://global/content/customizeToolbar.xul chrome://restclient/content/css/overlay.css
content/css/overlay.css:30:  list-style-image: url("chrome://restclient/content/images/icon16.png") !important;
content/css/overlay.css:33:  list-style-image: url("chrome://restclient/content/images/icon16.png") !important;
content/js/restclient.js:51:        i18nStrings = new restclient.StringBundle("chrome://restclient/locale/restclient.properties");
content/js/restclient.main.js:1040:      xslDocument.load("chrome://restclient/content/xsl/XMLPrettyPrint.xsl");
content/js/restclient.main.js:1053:      xslDoc.load("chrome://restclient/content/xsl/XMLIndent.xsl");*/
content/js/restclient.overlay.js:68:    browser.selectedTab = browser.addTab("chrome://restclient/content/restclient.html");
content/overlay.xul:2:<?xml-stylesheet href="chrome://restclient/content/css/overlay.css" type="text/css"?>
content/overlay.xul:7:  <script type="application/x-javascript" src="chrome://restclient/content/js/restclient.js" />
content/overlay.xul:8:  <script type="application/x-javascript" src="chrome://restclient/content/js/restclient.overlay.js" />
content/overlay.xul:23:                    image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:35:              image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:46:              image="chrome://restclient/content/images/icon16.png"
content/overlay.xul:58:              image="chrome://restclient/content/images/icon16.png"/>
modules/StringBundle.js:59: *     new StringBundle("chrome://example/locale/strings.properties");

Now, we could, and probably should, look through that manually for problems, but we can shorten the list quickly to find obvious problems with the command: grep -nri chrome: * | grep -v chrome://restclient/content/. This will give us any chrome: URIs which are not in the format for references to your add-on's content. The list obtained could easily contain valid chrome: URIs that reference files outside of your add-on. So, we might need to do more checking. From the above command we get:

content/js/restclient.js:51:        i18nStrings = new restclient.StringBundle("chrome://restclient/locale/restclient.properties");
modules/StringBundle.js:59: *     new StringBundle("chrome://example/locale/strings.properties");

The first is a locale chrome: URI. You do not specify a locale in your chrome.manifest. It is, therefore, certainly invalid. Looking at line 51 of content/js/restclient.js it is in active code. When it actually gets used, it will be invalid.

The second possibility is a typical example chrome: URI. The line begins with a * hinting that it might be a comment. Checking line 59 of modules/StringBundle.js shows that it is a comment.

The next step, if the problem had not already been found, would be to resolve the known invalid chrome: URI(s) and test to see if that solved the problem. In this instance, we already know what the problem is, so there is no need to check.

However, given that the chrome://restclient/locale/restclient.properties is invalid and A) there is no such file in your add-on and B) no locale defined in your chrome.manifest it means that if that code was executed it would fail. Basically it appears that function, restclient.i18n, is dead/bad code and should be removed. Given that function is the only use of the modules/StringBundle.js file, it could be removed also. Obviously, if this is something you are actively working on then that is a different story.

In working on this, I also noted a couple of other errors in the Browser Console which you should probably take a look at:

21:26:37.975 SyntaxError: test for equality (==) mistyped as assignment (=)?1 chrome://restclient/content/js/bootstrap.js:1557:33
21:26:37.989 TypeError: variable url redeclares argument1 chrome://restclient/content/js/restclient.main.js:376:8

While these are not inherently errors, it is generally desirable to not have anything show up in the Browser Console during the normal operation of your add-on. Although, given the various errors reported in jquery.js what are a couple more?