New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1564 users
Status: WontFix
Owner: ----
Closed: Jun 2011
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

  • Only users with Commit permission may comment.

Sign in to add a comment
Copying URL with non-ASCII character produces percent-encoded URL
Reported by, Jan 6 2011 Back to list
Chromium 10.0.629.0 (70535)
URLs (if applicable) : all other URLs
Other browsers tested:
  Firefox: OK

What steps will reproduce the problem?
In chromium bug copying and pasting links from Cyrillic :-(

What is the expected result?
expect a normal copy and paste links from the Cyrillic alphabetАррасская_уния

What happens instead?
paste URL

Please provide any additional information below. Attach a screenshot if
Tthat would link with the Cyrillic alphabet are not displayed and not copied in firefox like this:
open the configuration page about:config and set network.standard-url.escape-utf8 in false.
Obtain a result more understandable (correct) copy and a map linkАррасская_уния
Comment 1 Deleted
Comment 2 Deleted
Comment 3 Deleted
Comment 4 Deleted
Comment 5 Deleted
Comment 6 Deleted
Comment 7 Deleted
Comment 8 Deleted
Comment 9 Deleted
Comment 10 Deleted
Comment 11 Deleted
Comment 12 Deleted
Comment 13 Deleted
Comment 14 Deleted
Comment 15 Deleted
Comment 16 Deleted
Comment 17 Deleted
Comment 18 Deleted
Comment 19 Deleted
Comment 20 Deleted
The status of this bug is still "Unconfirmed".
It seems like developers does not care and wont fix it.

A reason might be that web standards allow only ascii characters in url,
and all unicode should be urlencoded.
The requested behaviour kinda does not conform to the standards.
In fact, an url is actually in the form we see from clipboard - this form is exact what is sent to web server.

Probably best way would be to develop chrome plugin/extension with desired functionality at additional button.
Comment 22 Deleted
Comment 23 Deleted
Comment 24 Deleted
Comment 25 Deleted
Comment 26 Deleted
Comment 27 Deleted
Comment 28 Deleted
Comment 29 Deleted
Comment 30 Deleted
Comment 31 Deleted
Comment 32 Deleted
Comment 33 Deleted
Comment 34 Deleted
Comment 35 Deleted
Comment 36 Deleted
Comment 37 Deleted
Comment 38 Deleted
Comment 39 Deleted
Comment 40 Deleted
Comment 41 Deleted
Comment 42 Deleted
Comment 43 Deleted
854 stars. it was about 200 yesturday. someone spammed the tracker?

Rather then flooding you'd better write a patch or extension.
Comment 45 Deleted
Comment 46 Deleted
Comment 47 Deleted
Comment 48 Deleted
Labels: Restrict-AddIssueComment-Commit
Locking, and deleting most of the comments, since it looks like someone linked to this bug and encouraged people to spam it with unhelpful comments.

For those who commented here just to say that you want it fixed: please don't ever do that; just star the bug. Flooding a bug with comments that don't add anything useful just makes the bug harder to deal with, and wastes time that could be spent fixing bugs.
Labels: -Type-Bug -Area-Undefined Type-Feature Area-WebKit
The links on are actually escaped in the source, so the link being copied is actually the link on the page. It looks like this is a request to automatically unescape urls as they are put onto the pasteboard (which seems like it has the potential to damage URLs if they weren't properly escaped in the first place...)
Status: Assigned
tkent, maybe you can take a look?
Labels: -Area-WebKit Area-UI
Owner: ----
Status: Available
Summary: Copying URL with non-ASCII character produces percent-encoded URL (was: NULL)
This is an expected behavior and we should not copy non-ASCII character in URL as is.

Adding 'Copy as Unicode' menu might be a solution of this issue?

Status: WontFix
Links on Wikipedia itself are a red herring, as comment 50 notes -- they're escaped in the page source.  The actual issue here is demonstrated by the link in comment 0.  We escape URLs when copying them.  This behavior matches Firefox 4 (by default) and Safari 5, though not IE9.

We added this behavior on  issue 2820  to fix a variety of problems in languages like Japanese.  Because those problems resulted in users unable to navigate to the pasted links, whereas this issue seems to be solely about cosmetics (in that escaped URLs are ugly and hard to read), preserving that behavior change seems like the more important thing to do.
Project Member Comment 54 by, Mar 11 2013
Labels: -Area-UI Cr-UI
Sign in to add a comment