271828 - Bad encoding of link with accented characters

Status: VERIFIED DUPLICATE of bug 284474

(Toolkit :: Toolbars and Toolbar Customization, defect)

Description

[Mina]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041123 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041123 Camino/0.8+

When clinking in this link <a href="#?string=Hétérogène">Hétérogène</a> in a web
page, I get this in the Location bar: "...?string=H%C3%A9t%C3%A9rog%C3%A8ne",
but in Firefox, I get "...?string=H%E9t%E9rog%E8ne".

This leads to problems eg. in PHP generated pages (when the var in the URL is
passed in the next page, the accented string isn't displayed correctly and can
break the web application).

Reproducible: Always
Steps to Reproduce:
1. Load the attached test case "accents.html"
2. Click on the link "Hétérogène"
3. Read the content of the Location bar

Actual Results:  
The end of the text in Location bar reads "...?string=H%C3%A9t%C3%A9rog%C3%A8ne"

Expected Results:  
The end of the text in Location bar should read "...?string=H%E9t%E9rog%E8ne"

Comment 1

[Mina]

Attachment: Testcase

Comment 2

[Mina]

This is a regression, it works with build 2004112408 (v0.8.2).

Comment 3

[Josh Aas]

Can you confirm that this is Camino-specific? Can you test on a Firefox trunk
nightly?

Comment 4

[Hiro]

The location bar was set to "view#?string=H%E9t%E9rog%E8ne" in build of the
following.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041129
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.5) Gecko/20041107 Firefox/1.0

Comment 5

[Mina]

Works correctly (i.e. "...?string=H%E9t%E9rog%E8ne") with

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041129
Firefox/0.9.1+

Comment 6

[Hiro]

WFM.

Mac OS X 10.3.6
trunk build of Camino
2004112821 (v0.8+)

Comment 7

[Mina]

WFM
Mac OS X 10.3.6, 
NB 2004113008 (v0.8+)

Comment 8

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

WFM now, too: 2004120108 (v0.8+)  (wasn't working on the build I was using this
afternoon, the 20041126 0.8+ NB)

Since the original reporter now WFM and I can also confirm WFM, should this bug
be closed?

Comment 9

[Josh Aas]

I can also confirm that this doesn't seem to be a problem any more (12/2/04
nightly). Closing.

Comment 10

[Mina]

I'm sorry to say that this is broken again :-(
Mac OS X 10.3.7
NB 2005011808 (v0.8+), 

Comment 11

[Hiro]

Windows version firefox reproduced.

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.8b) Gecko/20050120 Firefox/1.0+

Comment 12

[Hiro]

depend or duplicate bug145962 ?

Comment 13

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

(In reply to comment #12)
> depend or duplicate bug145962 ?

I'd vote neither, since that is an old bug, whereas this is a recent (though
perhaps periodic) regression.  

(Bug 145962--and the others mentioned in it--are the same types of problems in
other areas of the code, though.)

Comment 14

[Mike Pinkerton (not reading bugmail)]

what's the status here? someone said they could repro on win32. 

Comment 15

[Simon Fraser [no longer active]]

It happens in firefox too.

Comment 16

[Josh Aas]

-> xp, marking this toolkit for now since it happens in both FF and Camino

Comment 17

[Josh Aas]

Sent this bug to jshin since he's pretty good with encoding bugs afaik

Comment 18

[Jungshik Shin]

Well, your PHP script should be fixed to handle %-escaped UTF-8 in URL in light
of RFC 3987 (http://www.faqs.org/rfcs/rfc3987.html ). See bug 261929 and bug 284474)
A work-around is to set 'network.standard-url.encode-utf8' to false.


*** This bug has been marked as a duplicate of 284474 ***

Comment 19

[benc]

V/dupe.