187445 - Accents in location bar are encoded once typed.

Status: RESOLVED DUPLICATE of bug 105909

(SeaMonkey :: Location Bar, defect)

Description

[Dag Wieers]

User-Agent:       Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021203
Build Identifier: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021203

If you type in a website that contains accents, the browser encodes the
non-ascii (?) characters to some encoded form and shows that. It's OK to use an
encoded URL but the location bar should use the original IMO.

(What's even worse is that IE5 will encode "é" to "%C3%A9" while Mozilla encodes
"é" to "%E9", I don't know whath the proper handling is, but the Mozilla one
only works ;-)) I had to redirect the IE5 so that works too now ;-(( )

FYI Links, Netscape 3.0.4 and Netscape 4.08 handle it all well.

Reproducible: Always

Steps to Reproduce:
1. Go to the example URL
2.
3.
Actual Results:  
It encodes the string in my Location bar

Expected Results:  
I would have expected Mozilla to leave alone what I've typed. (Unless I really
get redirected !!)

I think it is important for most languages.

Comment 1

[Matthias Versen [:Matti]]

an accent or an umlaut are invalid in an URL.
Mozilla MUST convert this for the request and it's o.k. that Mozilla shows it in
the URL Bar because you should know that Mozilla corrected your WRONG url.

-> invalid

Comment 2

[Dag Wieers]

I'm not sure this is an invalid request.

I thought that unicode domain-names were already allowed ? How are you going to
support that ? Bothering users with ugly unicode-codes while they just want to
have understandable URLs ?

And since you have a uniform way to encode and decode it, I can't even imagine
that it is wrong after all.

If the only reason that it is wrong is because Mozilla must convert it for the
request. I'm even more convinced that it should be corrected. It's not because a
lower level protocol cannot use certain characters but has a perfectly well (and
well-used) work-around, that you have to bother the user with this short-coming
of a low-level protocol.

Please tell me where it says that it is wrong for a web-browser to show a user
an understandable URL instead of an encoded one.

Comment 3

[Matthias Versen [:Matti]]

>Please tell me where it says that it is wrong for a web-browser to show a user
>an understandable URL instead of an encoded one.

I can show you the RFC that this URL is invalid. 
We don't show the user an invalid URL and that is by design.

The other solution would be to reject the URL with a popup "invalid URL"

Comment 4

[Dag Wieers]

The RFC doesn't specify what's best for a user. The RFC specifies what the
low-level protocol will or won't accept. That's why you need to encode it for
the low-level protocol (not necessarily for the Location bar, which is the
interface to the user).

So yes, it is a bad URL for the low-level protocol. And no, it's not bad for the
user's interface to websites.

Can you please discuss with others or get a second opinion. Because by doing so
you will make it impractical for other users to use accented characters or any
other character set. (Even for domain-names with other character sets, it
is/becomes encoded and thus unusable)

Comment 5

[R.K.Aa.]

I would also like to see the RFC where it explicitly states that browsers should
display URL's as unreadable garbage in the urlbar if they contain national
characters. Netscape 4 and Konqueror have no problem displaying the url as
http://dag.wieers.com/personal/lyrics/Dévotion.php

Comment 6

[Dag Wieers]

Added the bug also to Galeon/Gnome's bugzilla
http://bugzilla.gnome.org/show_bug.cgi?id=102380

Mozilla is designed for "designed for standards compliance, performance and
portability", while Galeon is designed to be "the simplest interface possible
for a browser".

I guess my enhancement fits more in the second definition after all.

Comment 7

[Boris Zbarsky [:bzbarsky]]

This is all nice, but this is already filed and has been discussed before... 
please find the original bug.

Comment 8

[Dag Wieers]

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