After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672707 - epiphany should display urls in non-latin languages in a readable form
epiphany should display urls in non-latin languages in a readable form
Status: RESOLVED DUPLICATE of bug 596399
Product: epiphany
Classification: Core
Component: [obsolete] URL bar
3.6.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 424851 677382 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-03-23 17:34 UTC by Praveen A
Modified: 2012-10-08 03:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
epiphany vs iceweasel - non-latin urls (644.09 KB, image/png)
2012-03-23 17:39 UTC, Praveen A
  Details
Unescape strings for link messages and entry text (2.44 KB, patch)
2012-04-04 11:09 UTC, Zan Dobersek
none Details | Review

Description Praveen A 2012-03-23 17:34:45 UTC
Showing them as 5 escaped characters is not acceptable. A side by side comparison of how epiphany does it and how iceweasel/firefox does it is attached. Users expect to be able to read urls in their language and current implementation is a big i18n let down.
Comment 1 Praveen A 2012-03-23 17:39:47 UTC
Created attachment 210455 [details]
epiphany vs iceweasel - non-latin urls
Comment 2 Zan Dobersek 2012-04-04 11:09:45 UTC
Created attachment 211272 [details] [review]
Unescape strings for link messages and entry text

URLs and link messages are shown as escaped strings, making it
unreadable most of the times. Unescape these strings to correct
that.
Comment 3 Diego Escalante Urrelo (not reading bugmail) 2012-04-04 16:56:42 UTC
Problem with this is that copy-pasting from the location entry would not give a usable URL.
When copying the URL should be escaped.
Comment 4 Xan Lopez 2012-04-11 14:27:03 UTC
Also I'm not sure there's any reason to not do this in GTK+ itself?
Comment 5 Zan Dobersek 2012-04-20 14:57:33 UTC
(In reply to comment #4)
> Also I'm not sure there's any reason to not do this in GTK+ itself?

This is not necessarily the desired behavior, but could be chosen through something like gtk_entry_unescape_text. Again, it would not be necessarily desired to then escape the entry text on cutting or copying.

Given the current GtkEntry behavior[1] when copying, cutting and pasting the entry content, the solution would seem to be to connect to copy-clipboard and cut-clipboard signals and escape the clipboard content after the entry text was put into it. In the opposite manner, connecting to the paste-clipboard signal, the newly-pasted entry content would be unescaped.

[1] http://git.gnome.org/browse/gtk+/tree/gtk/gtkentry.c#n5202 to #n5252
Comment 6 Xan Lopez 2012-06-13 12:42:31 UTC
*** Bug 677382 has been marked as a duplicate of this bug. ***
Comment 7 Jean-François Fortin Tam 2012-10-08 02:09:27 UTC
*** Bug 424851 has been marked as a duplicate of this bug. ***
Comment 8 Jean-François Fortin Tam 2012-10-08 03:08:30 UTC

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