WebPositive – Cannot handle non-ASCII characters in location bar

[deejam]

Web positive cannot handle non-ascii characters in the location bar.

• When opening a url with non ascii characters, an error displays.
• When entering a search string in the location bar containing non-ascii characters, they are encoded wrong.

How to recreate the problems:

• Enter www.åre.se in the location bar. Expected behavior: redirection to www.are.se
• Enter åäö in the location bar. Expected behavior: google search for "åäö".

Attached are three images displaying the problem. GCC2 Hybrid, hrev40624. WebPositive hrev573.

[deejam]

Error when entering åre.se in the location bar

[deejam]

Enter åäö in the location bar

[deejam]

Search result for åäö with wrong character encoding

[axeld]

This might still be two different problems, though. IIRC URLs containing special characters might have to be escaped somehow - it's very well possible that ISC's libbind (which we use internally) doesn't have any support for this, and requires the caller to handle it.

Now I don't know if the usual "%20"-like escaping is used for the host address, too, but as you can see from the Google search URL, it's not escaped correctly, as it obviously does not expect UTF-8 input.

[vooshy]

A simple change to the way in which webpositive searches using google would fix this ticket - chrome uses sourceid and type before the data for the same search.

e.g. ​http://www.google.com/search?aq=f&sourceid=chrome&ie=UTF-8&q=%C3%A5%C3%A4%C3%B6

I'm assuming webpositive would be something like: ​http://www.google.com/search?aq=f&sourceid=webpositive&ieUTF-8&q=%C3%A5%C3%A4%C3%B6

[anevilyak]

Replying to vooshy:

A simple change to the way in which webpositive searches using google would fix this ticket - chrome uses sourceid and type before the data for the same search.

The sourceID parameter has absolutely nothing to do with it, that just tells google the fact that the search was submitted via Chrome's omnibar rather than directly off their site (for statistical/analytics purposes). That would in no way fix the fact that the characters are encoded incorrectly.

[vooshy]

sourceid aside - the link includes it is utf-8 which sorts out the google search from incorrect chars as per the screenshot.

[leavengood]

I think vooshy is right in regards to telling Google the input encoding, I added the built in search very quickly and intend to improve it and make use of search engine descriptions eventually, but now hard coding UTF-8 as the input format should help, at least for searches. I'm not sure what the right behavior is for URLs with special characters.

[anevilyak]

Replying to leavengood:

...but now hard coding UTF-8 as the input format should help, at least for searches. I'm not sure what the right behavior is for URLs with special characters.

I tried passing along the encoding here locally and as far as I can tell it made no difference, so it seems something's going wrong elsewhere along the line, but at the moment I'm not sure where/why.

[pulkomandy]

fixed in ​https://github.com/haiku/webkit/commit/aa592b873f7b8e0ec738cc2cdd4fba38eac60562

IDN domains don't really work yet, see you in #9063 !