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.
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.
Component: Networking → General
Product: Core → Firefox
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.
(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?
RE: geolocation. See original comment 0.
Assignee: nobody → dao
OS: Mac OS X → All
Hardware: x86 → All
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.
For electrolysis this should probably use gBrowser.currentURI.
(In reply to Tom Schuster [:evilpie] from comment #13) > For electrolysis this should probably use gBrowser.currentURI. This would regress bug 878924.
(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...
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Filed bug 883745 as a follow-up
Confirmed fixed m-c 2013-06-17.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.