878939 - WebRTC doorhanger shows IDN as punycode

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect)

Description

[Matt Wobensmith [:mwobensmith][:matt:]]

Attachment: WebRTC doorhanger with punycode

When a request for cam/mic comes from an origin that has a valid IDN, the WebRTC permission doorhanger displays the origin incorrectly. The domain token(s) that contain non-ASCII are displayed as punycode.

Other portions of the UI - address bar, tab title bar, status bar - display the correct IDN.

See attached screenshot.

For comparison, this does not affect the geolocation doorhanger, which correctly canonicalizes the domain name.

My own repro case was simulated with a local server. To reproduce, use a server of your own that allows wildcard subdomains, and add a subdomain with a non-ASCII character.

Comment 1

[Jason Smith [:jsmith]]

This is a bug, but a low priority one. I don't think I've ever seen in any of the top site testing I've done where UTF-8 characters was used for the host origin. Many cases host origins typically rely on ASC-II character sets, even in countries outside of the United States. For example, if I was in a Spanish locale and made use of a subdomain to represent a country-specific site, sites very commonly use es.yourhost.com.

Comment 2

[Matt Wobensmith [:mwobensmith][:matt:]]

Low priority bug, but to be clear, this isn't just about subdomains. It's about any IDN/Unicode domain, of which there are currently about one million registered with Verisign alone. 

Adding Simon, who did the most recent work for IDNs.

Should get fixed eventually.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Matt Wobensmith from comment #2)
> Low priority bug, but to be clear, this isn't just about subdomains. It's
> about any IDN/Unicode domain, of which there are currently about one million
> registered with Verisign alone.

Note - That's small in the grand context of all possible origins on the web.

> 
> Adding Simon, who did the most recent work for IDNs.
> 
> Should get fixed eventually.

A question that needs to be answered here is to find out if this applies to more than just the WebRTC doorhanger, as I would not be surprised if this happened with other permission doorhangers. What happens if you run this same test case with geolocation? desktop notifications?

Comment 4

[Matt Wobensmith [:mwobensmith][:matt:]]

RE: geolocation. See original comment 0.

Comment 10

[Simon Montagu :smontagu]

I pushed a patch to try at https://tbpl.mozilla.org/?tree=Try&rev=baa6c604c6d8 but am just off for a week's vacation so won't be able until after 2013-06-17.

Comment 11

[Dão Gottwald [:dao]]

Attachment: patch

Comment 12

[Dão Gottwald [:dao]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4aa873f715b3

Comment 13

[Tom S [:evilpie]]

For electrolysis this should probably use gBrowser.currentURI.

Comment 14

[Dão Gottwald [:dao]]

(In reply to Tom Schuster [:evilpie] from comment #13)
> For electrolysis this should probably use gBrowser.currentURI.

This would regress bug 878924.

Comment 15

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #14)
> (In reply to Tom Schuster [:evilpie] from comment #13)
> > For electrolysis this should probably use gBrowser.currentURI.
> 
> This would regress bug 878924.

I mean bug 876044...

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4aa873f715b3

Comment 17

[Simon Montagu :smontagu]

Filed bug 883745 as a follow-up

Comment 18

[Matt Wobensmith [:mwobensmith][:matt:]]

Confirmed fixed m-c 2013-06-17.