Comments on: Firefox 3: UTF-8 support in location bar

By: Sebastian

Sebastian — Sat, 04 Oct 2008 16:43:40 +0000

I would like to disable this feature as well to keep my URIs valid and copy-n-pastable. Please let me know how to do that. Thanks!

By: Alex

Alex — Mon, 07 Jul 2008 18:20:26 +0000

The only problem I have experienced is that the decode/encode is incorrect for resubmitting links. Example as follows.

I submit this:
http://www.google.com/search?q=%E2%80%A2

Firefox decodes %E2%80%A2 into a visible BULLET character.

When I edit the url, Firefox encodes is incorrectly as this:
http://www.google.com/search?q=%95

%95 is not a BULLET character in UTF-8. In Windows-1252, this is a BULLET, but in UTF-8, this is a MESSAGE WAITING character.

Firefox is misrepresenting my data-sending wishes!

Thoughts?

By: Gen Kanai

Gen Kanai — Tue, 24 Jun 2008 22:48:12 +0000

Hi, thanks for asking. Urls are a subset of uris (uniform resource identifier) and uri is the technically more accurate. Bernie Zimmerman has a good overview:

http://www.bernzilla.com/item.php?id=100

By: Uri?

Uri? — Tue, 24 Jun 2008 17:53:04 +0000

Is an “uri” the same thing as an “url”?

By: Johnathan Nightingale

Johnathan Nightingale — Mon, 16 Jun 2008 13:31:46 +0000

@Damian - It’s a bad idea to create a crappy experience for non-latin text, too.

The perceived incremental threat to rendering UTF-8 in the location bar assumes that people are otherwise good parsers of URLs, which is consistently shown to be false. Attackers already paper “paypal.com” all over subdomains and path segments in a URL, because they know unsophisticated users won’t know the difference. On the other hand, the downside of refusing to render IDN/UTF-8 properly is that a very large portion of the net gets a second-class experience.

This isn’t an argument that “things suck so who cares if we make them worse,” it’s a reminder that, one the one hand, benefit has to be weighed against cost, and on the other, that url tinkering is not the way to keep people safe. We keep people safe by removing complex URL semantics as a thing we expect users to understand - by actively blocking known badness, and by providing stronger (verified, revocable) identity information the rest of the time.

By: Damian Yerrick

Damian Yerrick — Mon, 16 Jun 2008 01:33:18 +0000

I thought it was a bad idea to show internationalized domain names (IDN) so that homoglyph attacks could be made more obvious. Or does this pertain solely to the path after the domain name (or to the corresponding part of a URN)?

By: andy

andy — Sat, 24 May 2008 11:44:07 +0000

How can I disable this? Spending sometime playing in about:config and I can’t do it.
Well to reply to my email, thank you. If I find the answer before you reply, I’ll post it.

By: Gen Kanai

Gen Kanai — Fri, 23 May 2008 21:38:03 +0000

Daniel, thank you for the clarification. I’ve updated the article accordingly.

Edward, yes- this is a gigantic, enormous win for the location bar usability. We will be focusing on this new i18n-enabled functionality whenever we talk about the AwesomeBar.

By: Edward Lee

Edward Lee — Fri, 23 May 2008 12:50:50 +0000

You can even do multi-word search in the AwesomeBar with those terms: Japanese in the uri: “wiki 日本”

By: Daniel Glazman

Daniel Glazman — Fri, 23 May 2008 11:24:50 +0000

Let me correct one thing only : you say Roman languages and non-Roman languages. That’s wrong. You should say latin-based writing scripts and non-latin-based writing scripts. And even that is a bit wrong. I am french, and french uses a latin writing script, but http://fr.wikipedia.org/wiki/Electricité with a trailing acute e is encoded in FF2… Same thing for http://sv.wikipedia.org/wiki/Umeå with a trailing a-circle. In URL, FF2 encodes anything beyond the us-ascii boundaries, really.