User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130307122351 Steps to reproduce: 1. Install the following add-on: ============== var tabs = require("sdk/tabs"); tabs.on("ready", function(tab){ console.log(tab.url); }); ================ 2. Open the following IDN in the browser: http://xn--mgbh0fb.xn--kgbechtv Actual results: info: tabenum: http://E+'D.%.*('1/%D8%A7%D9%84%D8%B5%D9%81%D8%AD%D8%A9_%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A%D8%A9 Expected results: tab.url returns "xn--mgbh0fb.xn--kgbechtv" for the host part of the url

Firefox seems to behave badly with that url as well: https://www.evernote.com/shard/s1/sh/5e373ddb-eb7e-4fca-9c1c-21994ae1d750/7426d13b0029970e8fb64e9eabd768f3

Update, the url seems to work for me now.

I don't think it's strictly an SDK issue. If I copy & paste the link from the location bar to any text editor, that's the result: http://مثال.إختبار/%D8%A7%D9%84%D8%B5%D9%81%D8%AD%D8%A9_%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A%D8%A9 That is also the exact value returned by `tab.url`: const tabs = require("sdk/tabs"); tabs.open({ url: "http://xn--mgbh0fb.xn--kgbechtv", onReady: function(tab) { require("sdk/clipboard").set(tab.url); } }); Plus, it's still a valid URL, that point to the same URL: const tabs = require("sdk/tabs"); tabs.open({ url: "http://xn--mgbh0fb.xn--kgbechtv", onReady: function(tab) { tabs.open(tab.url); // same site } }); I believe that the string that is shown by the console depends by the file we use to dump on screen, due a problem on Windows. Probably this extra step just messed up the encoding, and that part could be maybe considered a bug in the SDK – and we could have a look – but for what is related to the url representation, that should be fixed on platform side – if it's a bug.

This kind of caught me by surprise, because it's inconsistent with every other Firefox interface I have worked with. Site permissions, cookies, local storage all use the punycode representation. The GUI will sometimes (not for all TLDs) convert this back to unicode, but I would have expected to be isolated from such matters. This transformation really seems more like something that concerns the presentation layer and not the "under the hood" parts.