Closed Bug 62522 Opened 24 years ago Closed 23 years ago

Russian texts in form items (TEXT, TEXTAREA) aren't submitted well

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla0.9.8

People

(Reporter: mar_garina, Assigned: smontagu)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test10 i686; en-US; m18) Gecko/20001208 BuildID: 20001208 When I write some hebrew (probably some other non-english-language?) text in forms, inside a text box or textarea box: 1. it doesn't use the correct fonts set to hebrew, probably the western ones. 2. when I submit the form, it doesn't send, for some reason, the correct characters.. instead of hebrew characters I see '????' (it changed their ascii value, I guess). And no, it's not a font problem. it submits it wrong. Thanks. Reproducible: Always Steps to Reproduce: just type hebrew text in any text/textarea box. Actual Results: 1. fonts are western instead of being hebrew, while the page charset is set to hebrew. 2. It doesn't submit the correct text for some reason.. Expected Results: 1. if the page charset is set to hebrew (iso-8859-8), it should also make the font inside the boxes hebrew. 2. submit the text correctly.
eric this may be more of an editor bug than yours - reassigning
Assignee: rods → pollmann
Summary: Hebrew texts in form items (TEXT, TEXTAREA) isn't submitted well → Hebrew texts in form items (TEXT, TEXTAREA) aren't submitted well
How exactly are you inputing Hebrew? I suspect you don't a proper keymap with Hebrew X keysyms in it.
I insert hebrew with the proper keymaps. With netscape 4.x it worked and still works just great.
Reporter is this still occuring in the latest nightlies?
I foun dthe problem. I didn't use the real hebrew keymaps, but used 8bit (1-255) keymap. It works fine with hebrew with most programs, even with netscape, but not with mozilla. the question is if it worth adding mozilla 8bit-hebrew chars support. I think it's ok that way.
Marking WONTFIX as per reporters comments.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
I am seeing the same problem with russian, and I think it might be pretty serious, since it might effect many foreign search engines. I switched windows keyboard to russian and typed a string in a text box. When I submit it to an echo CGI it changed all the letters to question marks '??????'
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Marking NEW and changing the Summary to reflect reporters comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Hebrew texts in form items (TEXT, TEXTAREA) aren't submitted well → Russian texts in form items (TEXT, TEXTAREA) aren't submitted well
dup of/related to bug 43151?
Target Milestone: --- → Future
Workaround and recommended fix, hope they are for this bug $ uname -a Linux prof.10net 2.2.14-15mdk #1 Tue Jan 4 22:24:20 CET 2000 i686 unknown $ ./mozilla --version ... Mozilla/5.0 (X11; U; Linux 2.2.14-15mdk i686; en-US; 0.8.1) <developer build In order to work with russian language I edited two files: 1) unixcharset.properties $ diff unixcharset.properties unixcharset.properties.my 440c440,443 < locale.all.ru_RU=ISO-8859-5 --- > #locale.all.ru_RU=ISO-8859-5 # commented out dumb AIX&ISO encoding > # Correct encoding for Russia > locale.all.ru_RU=KOI8-R > locale.all.ru=KOI8-R 2) charsetalias.properties (not requred, but recommended to update) $ diff charsetalias.properties charsetalias.properties.my 172c172,173 < cyrillic=ISO-8859-5 --- > #cyrillic=ISO-8859-5 > cyrillic=KOI8-R 3) That steps are enough. But I recommend to run before mozilla: LC_ALL=ru LC_COLLATE=ru LC_CTYPE=ru LC_MESSAGES=ru LC_MONETARY=ru LC_CTIME=ru export LC_ALL LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_CTIME
Frank, I don't really know enough about these files to know if this is the correct fix. Can you take a look at it? Thanks!
Assignee: pollmann → ftang
Keywords: patch
Target Milestone: Future → ---
1) unixcharset.properties $ diff unixcharset.properties unixcharset.properties.my 440c440,443 < locale.all.ru_RU=ISO-8859-5 --- > #locale.all.ru_RU=ISO-8859-5 # commented out dumb AIX&ISO encoding > # Correct encoding for Russia > locale.all.ru_RU=KOI8-R This is not acceptable. you should not comment out these line. AIX did ship with ru_RU for ISO-8859-5 in AIX. I don't mind a platform overwrite- > locale.all.ru=KOI8-R This is ok 2) charsetalias.properties (not requred, but recommended to update) $ diff charsetalias.properties charsetalias.properties.my 172c172,173 < cyrillic=ISO-8859-5 --- > #cyrillic=ISO-8859-5 > cyrillic=KOI8-R This is not acceptable. According to IANA registration - ftp://ftp.isi.edu/in-notes/iana/assignments/ character-sets Name: ISO_8859-5:1988 [RFC1345,KXS2] MIBenum: 8 Source: ECMA registry Alias: iso-ir-144 Alias: ISO_8859-5 Alias: ISO-8859-5 (preferred MIME name) Alias: cyrillic Alias: csISOLatinCyrillic "cyrillic" is the alias for "ISO-8859-5" not "KOI8-R" Since bstell fix the nl_langinfo bug, I wonder do you really need to change the charsetData.properties file now at all. Reassign to bstell
Assignee: ftang → bstell
Would you check that the problem still exists? We now use nl_langinfo(CODESET) (bug 54000) to get the character set.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
no one reply after my comment. Mark this bug as fixed to force verification. move it to moz0.9.3 since it is not moz0.9.2 critical
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I can reproduce this on build 2001-08-06-03-trunk... russian font gets changed to ???? when submited. I faced this problem when searching for a russian song in audiogalaxy, I wasnt able to do that! There is no workabout! Reopening
Severity: normal → major
Status: RESOLVED → REOPENED
OS: Linux → All
Resolution: FIXED → ---
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
First of all, there's no need for no locales. Just 'setxkbmap ru' on any modern XFree86 distro and you'll be set (as long as xev sees Russian keysyms when you type them). Second, AudioGalaxy is probably an ISO-8859-1 page, and the encoding of the submitted data from a form is according to the encoding of the page the form is located on. Since Cyrillic characters cannot be represented in ISO-8859-1, they are converted to question marks. To solve this, try changing the encoding to WINDOWS-1251 (or whatever encoding those MP3 filenames are in) via View > Character Coding and try typing the search string again.
Thanks Ilya, I changed the encoding and audiogalaxy no longer submit the question marks...
based on the last comments should we mark this WORKSFORME?
I tested to see the behaviour of IE and Netscape 4.x when writing Russian on the audioglaxy.com site... IE: Writes the "cyrillic" letters as you type, but when submitted the letters are converted to something like "сплин", "accented latin characters", basicly ascii equivalents of the russian characters. NS4: Writes the letters as "accented latin characters" as you type, and are kept as "accented latin characters" once submited.Netscape6: Writes the "cyrillic" letters as you type, but when submited the letters are converted to "?????", question marks... I think Netscape 6 behaviour is incorrect, because it looses the original as?ii code. The data that you search for is in the same encoding as the page. You might not be able to read it, but you will still be able to search through and find a particular sequence of ascii characters. When all non letter characters are converted to question marks you will no longer be able to find that string... In IE after submitting the search string as wierd acii characters you can change the encoding, and then be able to read it in cyrillic, but in Netscape 6 once you've submitted the string there is no way of reading it... I dont know if I'm making sence, but to me this seems like data loss.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
reassign
Assignee: bstell → ftang
Status: REOPENED → NEW
move to m0.9.8
Target Milestone: mozilla0.9.6 → mozilla0.9.8
*** Bug 108144 has been marked as a duplicate of this bug. ***
simon- this user mention Hebrew. Can you take a look at this ?
Assignee: ftang → smontagu
I am trying to resolve an apparent contradiction between comment 17 and comment 19. Is the following a correct summary: (1) In Russian pages with an appropriate encoding there is no problem with form submission of Cyrillic characters. (2) At non-Russian sites like audiogalaxy Cyrillic characters are converted to ? characters so there is no way to search for Russian text (unlike IE and NS4 where the text can be found even though it is not rendered correctly). (3) There is a valid workaround for (2) by overriding the encoding before submission.
exactly :)
That behaviour is reasonable IMO, so I am marking WORKSFORME. I would only consider it data loss if there were no way at all to submit the data.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
verifying on build 2002-03-01-03-trunk
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.