Links in "view source" for IDN pages refer wrong URIs

RESOLVED FIXED in mozilla6



10 years ago
8 years ago


(Reporter: yuki, Assigned: niklas)


Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)




(2 attachments)



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090704 Shiretoko/3.5.1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090704 Shiretoko/3.5.1pre (.NET CLR 3.5.30729)

In "view source", "href" and other attributes are linkified automatically. However, if the URI of the original page has IDN, most links don't work correctly.

Reproducible: Always

Steps to Reproduce:
1. Go to "http://例え.テスト/" (this is an IDN, punycode version is "http://xn--r8jz45g.xn--zckzah/")
2. "View" => "Page Source"
3. Click a link in the tag:
   <link rel="shortcut icon" href="/images/favicon.ico" />

Actual Results:  
Firefox tries to load "view-source:http://%c3%a4%c2%be%c2%8b%c3%a3%c2%81%c2%88.%c3%a3%c2%83%c2%86%c3%a3%c2%82%c2%b9%c3%a3%c2%83%c2%88/images/favicon.ico" and shows "Server not found" error.

Expected Results:  
Firefox loads "view-source:http://xn--r8jz45g.xn--zckzah/images/favicon.ico".

Comment 1

10 years ago
FYI: the protocol handler for "view-source:" uses "asciiSpec" instead of "spec", to get punycode version of the URI.


10 years ago
Component: General → View Source
Product: Firefox → Toolkit
QA Contact: general → view.source
Version: unspecified → 1.9.1 Branch

Comment 2

10 years ago
Confirmed on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Ever confirmed: true

Comment 3

9 years ago
I can confirm this bug on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a2pre) Gecko/20100216 Minefield/3.7a2pre.

This bug appears only if used top level domain is whitelisted to interprest punycode.


9 years ago
Duplicate of this bug: 556815


8 years ago
Version: 1.9.1 Branch → Trunk


8 years ago
OS: Windows Vista → All
Hardware: x86 → All

Comment 5

8 years ago
I just noticed this bug on http://fö

Comment 6

8 years ago
Created attachment 504150 [details] [diff] [review]
Fetch the absolute URL, convert it according to IDNA

I can confirm this with latest hg checkout, patch attached.

I use the same method as documented in /netwerk/protocol/viewsource/nsViewSourceHandler.cpp, Line 85


8 years ago
Attachment #504150 - Flags: review?(jst)
Assignee: nobody → niklas
Duplicate of this bug: 645129


8 years ago
Attachment #504150 - Flags: review?(jst) → review?(bzbarsky)
Hmm.  But GetSpec should work as well, I'd think, as long as the encoding is not confused....  Is the problem in the output of GetSpec (in that it's %-escaping inside the hostname before returning the value) or in what code later on does with the string GetSpec produced?
Niklas, ping?
Comment on attachment 504150 [details] [diff] [review]
Fetch the absolute URL, convert it according to IDNA

I believe the real problem is here, further down in the method in question:


That converts absoluteLinkUrl to UTF-16 by byte-inflating instead of doing a proper UTF-8 to UTF-16 conversion.
Attachment #504150 - Flags: review?(bzbarsky) → review-
Created attachment 527722 [details] [diff] [review]
Do the append right

And indeed, fixing that fixes the behavior of the steps from comment 0.
Attachment #527722 - Flags: review?(mrbkap)
Stealing so I can track this.

Niklas, are you OK with me crediting you for the fix from comment 11?  It's basically your work, since you found where things are going wrong....
Assignee: niklas → bzbarsky
Priority: -- → P2
Whiteboard: [need review]

Comment 13

8 years ago
Hey, sorry for not replying to your questions but i didn't have the sourcecode checked out anymore and i thought i would do it when i had time.

I didn't really understood what went wrong, i just applied the same method that was used in nsViewSourceHandler.cpp. As long as it is now fixed (correctly even), i'm happy. Credit is fine, no credit is also fine. Thanks for looking at it. :)
No problem.  Now all I need is to get Blake to review... ;)


8 years ago
Attachment #527722 - Flags: review?(mrbkap) → review+
Whiteboard: [need review] → [need landing]
Assignee: bzbarsky → niklas
Last Resolved: 8 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla6
You need to log in before you can comment on or make changes to this bug.