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 424851 - address autocompletion doesn't work with non ASCII
address autocompletion doesn't work with non ASCII
Status: RESOLVED DUPLICATE of bug 672707
Product: epiphany
Classification: Core
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Marco Pesenti Gritti
Depends on:
Blocks: 423036
 
 
Reported: 2007-03-31 13:17 UTC by Denis Jacquerye
Modified: 2012-10-08 02:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Denis Jacquerye 2007-03-31 13:17:33 UTC
The autocompletion doesn't work with non ASCII characters.

For example:
- open a sample file "file:///home/moyogo/Desktop/école"
- open a sample file "file:///home/moyogo/Desktop/ecole" only ASCII in the name
- start typing "file:///home/moyogo/Desktop/é" and nothing is offered as history
- start typing "file:///home/moyogo/Desktop/e" and the right address is offered as history

This should also do Unicode normalization of strings.
See 423036 for details. 
In short typing "é" or "é" (canonically equivalent) should suggest the same address from history.
Comment 1 Diego Escalante Urrelo (not reading bugmail) 2007-04-04 06:44:05 UTC
That's because the url is converted to %something. I recall there was a similar problem with the pages about not fully loaded sites (crasher suspects).
It was a matter of changing the variable that was being read.

I imagine this is just a matter of choosing what to save to the EphyNode (the url I mean)?

Chpe, ideas?
Comment 2 Christian Persch 2007-05-30 13:13:21 UTC
That is a fundamental problem deep in gecko/gtkmozembed, not easy to fix.
Comment 3 Cyril Brulebois 2007-09-06 23:15:16 UTC
Christian, do you think that someone should at least try to have a look at fixing this bug? I'd be willing to do so -- though as you might have noticed, I'm quite new here.
Comment 4 Christian Persch 2007-09-07 21:32:22 UTC
I think this is going to be rather complicated.

We cannot store the URL in normalised form, since the URL is given by the page/server and it might not understand the normalised form. That means we'd have to normalise while doing the matching, which would slow it down even more (it's already slow)...

Also I'm not sure how you'd even implement this... normalising to NFD and stripping all combining characters, then comparing, maybe... ?
Comment 5 Jean-François Fortin Tam 2012-10-08 02:09:27 UTC

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