I gave a deeper look into this and it looks like there is no easy way to retrieve the "not normalized ascii url" (the one in the original IDNA format), e.g. by using URL (https://developer.mozilla.org/en-US/docs/Web/API/URL) we can easily convert the IDNA format into the normalized url: `(new URL("http://xn--80aj.com")).href` => "http://еа.com" but no easy way to do the opposite and convert "http://еа.com" into the more explicit "http://xn--80aj.com". After giving the attached example a try and explored it by making some experiments on top of it, I think that I agree with Robert. Besides the performance impact that converting the url back to the original IDNA format can introduce in an extension, the current behavior can be misleading because if the url is already encoded, any equality test needs to use the same encoded string, which is going to make the code harder to read (e.g. how can you easily know, by looking at the code and/or the manifest.json file of a webextention, if the extension is targeting the url "http://еа.com" (the encoded version of "http://xn--80aj.com") or the plain "http://ea.com"? On the bright side in our webRequest internals we have access to both the encodings as part of the nsIURI properties, in particular: - uri.asciiSpec is the url in the original IDNA format ("http://xn--80aj.com") - uri.spec is the encoded url ("http://еа.com") we are currently using `uri.spec` everywhere, e.g. the one related to the onBeforeRequest: - http://searchfox.org/mozilla-central/rev/24c443a440104dabd9447608bd41b8766e8fc2f5/toolkit/modules/addons/WebRequest.jsm#735 but there are also the originUrl and the documentUrl: - http://searchfox.org/mozilla-central/rev/24c443a440104dabd9447608bd41b8766e8fc2f5/toolkit/modules/addons/WebRequest.jsm#747,751 If we opt to change the url format on webRequest.onBeforeRequest, we should also do the same for the other webRequest events, and we should also evaluate what this means for the host permissions, the url filters and for the other API that can have similar issues (e.g. the webNavigation and tabs details). I'd like to hear Shane opinion on what described above.
Maybe related with bug 945240.