User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20061120 Camino/1.2+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20061120 Camino/1.2+ Steps to Reproduce: 1. hove over http://www.%67oogle.com/ Actual Results: status bar shows http://www.google.com/ Expected Results: status bar shows http://www.%67oogle.com/
12 years ago
No longer depends on: 361816
Component: Toolbars & Menus → Embedding: Docshell
OS: Mac OS X 10.3 → All
Product: Camino → Core
QA Contact: toolbars → docshell
Hardware: Macintosh → All
Summary: Status bar incorrectly unescapes percent encoded hostnames → nsWebShell::OnOverLink incorrectly unescapes percent encoded hostnames
*** Bug 361819 has been marked as a duplicate of this bug. ***
*** Bug 361818 has been marked as a duplicate of this bug. ***
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsWebShell.cpp&rev=1.680&mark=891#862 biesi points out that perhaps this is a problem with UnescapeURIForUI's implementation.
Interestingly enough, 2006112022 (1.2+) doesn't seem to have this problem.
Yeah, that is indeed the problem. It looks like this and the FILE_NOT_FOUND error handling in docshell are basically the only callers of unEscapeURIForUI that pass in a complete spec. We should probably just have a separate API for this (one that will unescape all but the scheme and hostname, I guess?)....
Where is it written that we shouldn't unescape hostnames? What about IDNs? Examples: http://r%C3%A4ksm%C3%B6rg%C3%A5s.josefsson.org http://%E7%B4%8D%E8%B1%86.w3.mag.keio.ac.jp
It seems I was misled by the fact that "View Selection Source" escapes hostnames in URIs (perhaps that should also be fixed?). In the page that I copied those examples from, http://www.w3.org/2003/Talks/0425-duerst-idniri/slide12-0.html , they are not escaped.
I still think this is invalid (per RFC 3986), but anyway it's a dupe. *** This bug has been marked as a duplicate of 304905 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
(In reply to comment #8) > I still think this is invalid (per RFC 3986), but anyway it's a dupe. I agree. For instance, see bug 309671.
You need to log in before you can comment on or make changes to this bug.