532047 - can't open IDN url from external app

Status: RESOLVED DUPLICATE of bug 309671

(Firefox :: Address Bar, defect)

Description

[John Daggett (:jtd)]

John Gruber uses IDN urls in his Daring Fireball Twitter feed.  These don't open correctly in Firefox when opened from an external app.  

http://daringfireball.net/linked/2009/11/27/df-twitter

"(Yes, some Twitter clients don’t correctly parse the ✪df.ws URLs. That’s because these Twitter clients have bugs. Also, yes, when you open one of these URLs in Firefox on Mac OS X, you have to manually hit Reload. Again, this is a bug in Firefox. Don’t ask me to use another domain name for the shortened URLs. If no one uses IDN domain names, what will motivate developers to fix (or work around) IDN bugs?)"

Steps to reproduce:

1. Make Firefox the default browser
2. Install a third-party Twitter app, Tweetie for Mac for example:

  http://www.atebits.com/tweetie-mac/

3. Run Tweetie (or other app)
4. Show tweets of a user (Tweetie: Twitter > Go to User...)
5. Enter user 'daringfireball'
6. Click on one of the links (e.g. http://✪df.ws/e82)

Expected result: page should display
Actual result: "server not found" error

Select the URL, copy, paste and hit enter.  Page now displays.

Web based twitter feed works fine, clicking on the URLs opens up the links correctly.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I just tried clicking the link from step 6 in the comment 0 bugmail and got the right thing loaded.  Though it did look like Thunderbird passed punycode over to Firefox in that case.

I'll give this a shot with Tweetie tomorrow.

Comment 2

[Jo Hermans]

dupe of bug 498803 / bug 517697 ?

Comment 3

[John Daggett (:jtd)]

(In reply to comment #1)
> I just tried clicking the link from step 6 in the comment 0 bugmail and got the
> right thing loaded.  

Right, from another webpage it's fine, it only seems to be a problem when opened from *outside* the browser.

(In reply to comment #2)
> dupe of bug 498803 / bug 517697 ?

These are definitely related but I'm not sure the testcases are precisely the same, they both involve copying the URL rather than clicking from outside the browser.  Once we track down the underlying cause we can decide if they are separate issues or the same one.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Right, from another webpage it's fine,

What does a webpage have to do with it?  I clicked a link in Thunderbird and it opened in Firefox.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Uh... does tweetie require a twitter account to use?  If so is there a str that doesn't include creating such an account?

Comment 6

[Karl Tomlinson (:karlt)]

FWIW, this works fine on Linux, both when starting a new Firefox instance and when opening a new page through XRemoteClient.  That's passing the UTF-8 text as an argument.

Comment 7

[philippe (part-time)]

(In reply to comment #5)
> Uh... does tweetie require a twitter account to use?  If so is there a str that
> doesn't include creating such an account?

1. From Minefield, copy that part of comment 0 with the offending url.
2. Open TextEdit on your Mac, New document -- rich text. 
3. paste the text. The URL should show as link.
4. Click on the link --> error page in Gecko 1.9.0 and newer.

Comment 8

[philippe (part-time)]

Attachment: test document

(In reply to comment #7)

... or download this test document, open in TextEdit.

Comment 9

[Boris Zbarsky [:bzbarsky]]

philippe, thanks!  Looking into this.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Ok, using the steps from comment 7, what gets handed to nsCommandLine::ResolveURI is the string "http://%E2%9C%AAdf.ws/e82"

This is also the value of |ar| in dch_handle, which is called by what looks like EnumRun in nsCommandLine.cpp.

When EnumRun is called, aThis->mArgs has length 2, and the args are: "-url" and "http://%E2%9C%AAdf.ws/e82" respectively.  This is what we're actually being passed on the command-line.

Now you can reproduce the observed behavior without any need for an external app: take that %-encoded string, paste it in your url bar, hit enter.  Then focus the url bar again and hit enter.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Oh, and you can also see the same behavior with http://we%62.mit.edu/ but the difference there is that the URL bar does NOT unescape ASCII characters in the string it shows.  So you can keep hitting enter to your heart's content and it'll keep loading the same URI, whereas with the non-ASCII case here the URI ends up different.  See also bug 304905.

Note that Thunderbird worked for me because it used punycode, not %-encoding, for the hostname.

So to get this bug it sounds like the app sending us the URI needs to ASCII-fy the string itself, and it needs to use %-encoding for the hostname.  Then we'd hit bug 309671.  That bug could use an owner; it's got a patch that just needs to be updated to review comments.