Opened 13 years ago

Closed 10 years ago

#7272 closed bug (fixed)

WebPositive – Cannot handle non-ASCII characters in location bar

Reported by: deejam Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (3)

WebPositive_error_non_ascii.png (5.0 KB ) - added by deejam 13 years ago.
Error when entering åre.se in the location bar
WebPositive_google_non_ascii.png (45.3 KB ) - added by deejam 13 years ago.
Enter åäö in the location bar
WebPositive_google_non_ascii_result.png (74.1 KB ) - added by deejam 13 years ago.
Search result for åäö with wrong character encoding

Download all attachments as: .zip

Change History (13)

by deejam, 13 years ago

Error when entering åre.se in the location bar

by deejam, 13 years ago

Enter åäö in the location bar

by deejam, 13 years ago

Search result for åäö with wrong character encoding

comment:1 by axeld, 13 years ago

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.

comment:2 by vooshy, 13 years ago

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

in reply to:  2 comment:3 by anevilyak, 13 years ago

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. That would in no way fix the fact that the characters are encoded incorrectly.

Version 0, edited 13 years ago by anevilyak (next)

comment:4 by vooshy, 13 years ago

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

comment:5 by leavengood, 13 years ago

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.

in reply to:  5 comment:6 by anevilyak, 13 years ago

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.

comment:7 by pulkomandy, 10 years ago

Owner: changed from leavengood to pulkomandy
Status: newassigned

comment:8 by pulkomandy, 10 years ago

Summary: WebPositive – Cannot handle non-ascii characters i location barWebPositive – Cannot handle non-ASCII characters in location bar

comment:9 by pulkomandy, 10 years ago

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

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

comment:10 by pulkomandy, 10 years ago

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.