If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED INCOMPLETE

Status

Add-on SDK
General
P2
normal
RESOLVED INCOMPLETE
5 years ago
11 days ago

People

(Reporter: Ove Soerensen, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.

Updated

5 years ago
Priority: -- → P2
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.
(Reporter)

Comment 4

5 years ago
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.
Blocks: 821779
https://bugzilla.mozilla.org/show_bug.cgi?id=1399562
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.