125034 - Form fields does not recognize ISO-8859-9 specific glphyes

Status: VERIFIED DUPLICATE of bug 117422

(Core :: Internationalization, defect)

Description

[Ecmel Ercan]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.0.3 (X11; Linux i586; U;) Gecko/20020205
BuildID:    20020205

Scedilla, scedilla, Gbreve, gbreve, dotlessi and Idotabove glphyes are not
recognized by the form fields.  If those characters are entered into  
the form fields, following chars are simply ignored.



Reproducible: Always
Steps to Reproduce:
1.Open Yahoo
2.Enter one of the above mentioned chars into the search field
3.Press search

Actual Results:  The chars following those glphyes are ignored.

Comment 1

[Yuying Long]

Thanks for report, but it should be really great that you can let us know some
more details:
1. Which locale were you using?
2. which charset and auto-detect option did you choose when you had this
problem?  If you change charset to a specified language charset by go to View |
Character Coding | More, doesn't it make any difference?
3. If you have windows system available there, could you please try this on
windows system to see if can reproduce it as well.

Comment 2

[Roy Yokoyama]

This may be related to surrogate support checkins. (well, maybe not...)
Anyways I will assign this to shanjian.

Comment 3

[Ecmel Ercan]

Hi,  here are the answers:

1. Which locale were you using?

tr_TR

2. which charset and auto-detect option did you choose when you had this
problem?  If you change charset to a specified language charset by go to View |
Character Coding | More, doesn't it make any difference?

Autodetect = off

If I change it to Turkish (ISO-8859-9) it works.  But someone may want to search
for a Turkish word in a none-turkish page. Also, I tried UTF-8 but it does not work.

3. If you have windows system available there, could you please try this on
windows system to see if can reproduce it as well.

No, it happened on Linux only.


Hope helps.

Comment 4

[Yuying Long]

Thanks a lot!  Confirm.

Comment 5

[Shanjian Li]

Reporter,
As a non-turkish speaker, I find it difficult to reproduce the problem. So would
you mind post a detail description about each step? To be specific, could you
post your search term in this bug comment so that I can copy-n-paste? (Of cause,
you have to let me know the encoding your are using.)
Please also post the desired result and undesired one on linux. (Either capture
of the screen or locale copy of the result page should be fine.) 

thanks

Comment 6

[Shanjian Li]

Reporter,
As a non-turkish speaker, I find it difficult to reproduce the problem. So would
you mind post a detail description about each step? To be specific, could you
post your search term in this bug comment so that I can copy-n-paste? (Of cause,
you have to let me know the encoding your are using.)
Please also post the desired result and undesired one on linux. (Either capture
of the screen or locale copy of the result page should be fine.) 

thanks

Comment 7

[Görkem Çetin]

Hi,

Let me give you some clues about this problem. Please copy any of the 
following characters

ý ð þ

and use them in a field. Set your environment variable LANG=tr_TR beforehand. 
You'll see that whenever you use one of those chars, the following string are 
not get posted to the web server. i.e use a string like that inside a form 
field:

This is a test string 1. ý  This is test string 2.

And submit. "This is test string 2" will never be posted to query.

Is this info enough? I can assist you more if you wish. Thanks. 

(note that my bugzilla entry is a perfect example for this problem. I cannot 
post this additional comment from Mozilla, I have to use Konqueror. Any 
characters following ý , ð  or þ would not be displayed after I pressed 
"Commit" button :-))

Comment 8

[Shanjian Li]

accept.

Comment 9

[Mehmet D. AKIN]

I think Bug 117422 covers Gorkem's concerns and its fixed about 3 weeks ago.
If these bugs are adressing the same thing, this bug should be marked as a 
duplicate.

Comment 10

[Mehmet D. AKIN]

Can reporter verify this bug had been resolved?  Bug 117422 fixed this.

Comment 11

[Shanjian Li]

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

Comment 12

[Yuying Long]

Mark as dup.  Please re-open if still see the problem.

Comment 13

[Ahmet A. Akin]

Turkish characters: 
ç Ç ğ Ğ ı İ ö Ö ş Ş ü Ü
encoding: Western (ISO-8859-1)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030304 Phoenix/0.5

Comment 14

[Ahmet A. Akin]

Trying with Mozilla

Turkish characters:

ç Ç ğ Ğ ı İ ö Ö ş Ş ü Ü 

Coding: Western ISO-8859-1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20021218

Comment 15

[Ahmet A. Akin]

Ok, first of all, sorry for the spam. But, i had to do that. Let me explain the
problem. In mozilla and phoenix, when default page coding is western, or "i
think" page is designed for western, some turkish characters in the form entries
are not recognized correctly (tried it in bugzilla especially). And it causes
data loss (see comment 13 and 14). 

it, instead, converts those Turkish characters to strings such as "ğ" or
"ş" and changing the coding after this conversion does not make page
showing correct turkish characters. 

In mozilla, choosing the defult coding as "Turkish" from preferences fixes this
problem, but actual problem still remains. In phoenix, since it does not have an
option for "default coding" this causes serious problems. In IE, this conversion
is not happening, only some other bizarre characters are appearing but and after
changing the coding to turkish, characters looks correctly again. 

i am suggesting to open this bug or you can direct it to another bug, if there
is any about this issue. i will provide screen shots about this issue.