468005 - opening URL in Firefox from external application fails to transliterate Unicode characters

Status: RESOLVED DUPLICATE of bug 309671

(Core :: Widget: Cocoa, defect, P3)

Description

[Spencer Wohlers]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

When I click "Open URL" in Terminal.app or run the command "open -a Firefox http://☃.net/", Firefox tries to open the page "http://www.☃.net/", which does not exist. "open -a Safari http://☃.net/" works fine though.

Reproducible: Always

Steps to Reproduce:
1. Open Terminal.app.
2. $ open -a Firefox http://☃.net/
Actual Results:  
Page not found error.

Expected Results:  
Firefox opening the page http://☃.net/ (http://xn--n3h.net/).

Comment 1

[Spencer Wohlers]

Okay, apparently http://www.☃.net/ does exist, in virtue because http://www.xn--n3h.net/. However, Firefox is not transliterating it properly when using the 'open' command (turning "☃" into "xn--n3h").

open -a Firefox http://www.☃.net/ does not work either.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Interestingly, invoking Firefox as follows (from a Terminal prompt)
works just fine:

/Applications/Firefox.app/Contents/MacOS/firefox-bin http://☃.net/

But the following doesn't:

/Applications/Firefox.app/Contents/MacOS/firefox http://☃.net/

This (and what you report) may to some extent be Firefox's fault.  But
I suspect there's also a healthy does of OS wierdness (possibly
AppleScript wierdness).

Comment 3

[Steven Michaud [:smichaud] (Retired)]

healthy does -> healthy dose

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It may be an AppleEvent-related bug, but it seems more likely to me that we're not responding "properly" to URLs we get in AppleEvents (that is, we're expecting URLs to be ASCII and/or punycode and not escaped UTF-8--which might not be an unreasonable expectation).

I wrote a short handler app to respond to "open -a" and then display what was passed in, and it looks like "open" is sending escaped UTF-8, "http://%E2%98%83.net/".

However, the fact that invoking the binary itself directly with the command-line handler for urls (/Applications/Firefox.app/Contents/MacOS/firefox-bin http://☃.net/ for Firefox, /Applications/Camino.app/Contents/MacOS/Camino -url http://☃.net/ for Camino, though I suspect Camino has a separate bug from everyone else) sounds like maybe certain codepaths *are* getting this escaped UTF-8-to-punycode translation performed but the AppleEvent path is not.

Steven's comment 2 sounds like input via the "firefox" shell script also is not getting this translation performed.

Comment 5

[Chris Gonyea]

I think I am also running into this bug. Where I am seeing this happen is on daringfireball.net's twitter feed. He uses a URL shortener that Firefox doesn't properly translate the characters into punycode.

Example post from Twitter:
http://twitter.com/daringfireball/status/13821615887

Click the link in his tweet and you will see Firefox cannot open the page. However, copy and paste the link into Firefox and it works properly.

Comment 6

[Chris Gonyea]

I should note, the example in comment 5 seems to only be replicated if you are viewing the URL in an external application (in my case, I am using Tweetie but I have replicated it in other Twitter clients). Going to the Twitter page in your web browser and clicking the link works.