849773 - The tabs-module does not work properly with internationalized domain names (IDNs)

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P2)

Description

[u463949]

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

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Firefox seems to behave badly with that url as well:

https://www.evernote.com/shard/s1/sh/5e373ddb-eb7e-4fca-9c1c-21994ae1d750/7426d13b0029970e8fb64e9eabd768f3

Comment 2

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Update, the url seems to work for me now.

Comment 3

[Matteo Ferretti [:zer0] [:matteo]]

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.

Comment 4

[u463949]

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.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562