Closed
Bug 63029
Opened 24 years ago
Closed 23 years ago
Japanese input in text area in forms confuses subsequent input
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: tarahim, Assigned: tetsuroy)
References
()
Details
(Keywords: intl, Whiteboard: checked-in)
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
override BeginComposition() and making ResetIMETextPWBuf() public in order to reset mPasswordIMEText
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
This has been happening quite some time, but I can not find a bugzilla entry.
MTrunk 200012148.
In a text area in a form, if I type a Japanese text instead of ASCII and delete
them, subsequent input gets confused.
For example, if I type Japanese text in the password area of the URL, delete it
and type a correct one in ASCII mode, only asterisks corresponding to the ASCII
text are visile. Then I hit sign in, and the server returns password error.
Then I go back one step, and now the text area shows a long stretch of asterisks
twice as long as the actual text input in ASCII.
IME used is KOTOERI. This happens in MacOS 8.6 and 9.04.
Reporter | ||
Comment 2•24 years ago
|
||
I am seeing a seemingly related weird behavior:
The cursor is not in the text area or in a textarea, and you type something in
Japanese input mode but do not hit return to complete the conversion. Then you
click in another textarea and hit delete.
Result: the text previously typed minus one last character appears. Hit delete
again, and the same text is added minus another character, repeatable until no
charcter in the text buffer is left.
Comment 3•24 years ago
|
||
Change the platform to all, I can also reproduce this.
Easier way to reproduce this inside NEtscape
1. visit http://warp/u/ftang/utf8test/example-8.html
2. this page do not have meta tag, so change the View Character Set to East
Asian:Japanese (Shift-JIS)
3. type 'aaa' and switch to Japanese keyboard and hit 'aaa' in the user field
4. after commit, hit [delete] (or Backspace in PC) 3 times,
5. do step 3 and 4 in the password field also.
in the echo.cgi, it show that Japanese text in user name are deleted but in the
password field, every one Japanese character are treated input duplicate
Mark the platform as all. I think the problem code is in the layout code,
probably nsFormFrame or nsFormControl.cpp
IME related bug, now reassign to yokoyama to work on.
Mark the priority as P4 since it only happen in the password field and only when
IME get involved. Very interesting, try the following
1. in PC
2. turn on IME
3. change the Japanese input method setting to halfwidth/EnglishNumeric (not
direct input).
4. type both "abcdefg" and commit in user field and password field
5. hit submit
6. see the result. it seems the count of the duplicate in the password is
related to the length of the input. For example, if I type "ab" , I will get
"aab", if i type "abc", I will get "aaabcb" , if I type "abcd", I will get
"aaaabcdbcb"
here is the table
Input Got
ab aab
abc aaabcb
abcd aaaabcdbcb
abcde aaaaabcdebcdebcdbcb
Comment 4•24 years ago
|
||
removing myself from cc list, adding rods and pollmann.
Updated•24 years ago
|
Assignee: ftang → yokoyama
Comment 5•24 years ago
|
||
reassign to yokoyama. yokoyama, please try this. I believe there are some bug in
the password field handling. I believe the bug is inside layout.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → ---
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla1.0
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 7•23 years ago
|
||
Moving to M0.9.2 for triage, because it is marked as P2 | Major. Mrking as
nsCatFood.
Ftang - Let's discuss during i18n triage.
Keywords: nsCatFood
Summary: Japanese input in text area in forms confuses subsequent input. → Japanese input in text area in forms confuses subsequent input
Target Milestone: Future → mozilla0.9.2
Assignee | ||
Comment 8•23 years ago
|
||
Assignee | ||
Comment 9•23 years ago
|
||
The fix is to
- maintain the index of PasswordBuf at the start of IME
- maintain the old IME text
- remove the old IME text from PasswordBuf
I defined a couple of methods to support the above=
nsresult nsTextEditRules::RemoveIMETextFromPWBuf();
nsresult nsTextEditRules::ResetIMETextPWBuf();
The code is executed if
(mFlags & nsIPlaintextEditor::eEditorPasswordMask) condition is met.
ftang: please review.
Thanks
Whiteboard: waiting for /r=
Assignee | ||
Comment 10•23 years ago
|
||
jfrancis: can you review my patch?
Comment 11•23 years ago
|
||
I have talked with Roy about this, and made some suggestions for the patch.
Assignee | ||
Comment 12•23 years ago
|
||
Assignee | ||
Comment 13•23 years ago
|
||
jfrancis: can you review my patch? I thank you for your time. :)
Comment 14•23 years ago
|
||
For:
+NS_IMETHODIMP
+nsPlaintextEditor::BeginComposition(nsTextEventReply* aReply)
+{
+ if(mFlags & nsIPlaintextEditor::eEditorPasswordMask) {
+ if (mRules) {
+ nsIEditRules *p = mRules.get();
+ nsTextEditRules *textEditRules = NS_STATIC_CAST(nsTextEditRules *, p);
+ textEditRules->ResetIMETextPWBuf();
+ }
+ }
I would add an else return NS_ERROR_NULL_POINTER if the test for mRules fails.
This should never happen but if it does we cannot properly handle commit, so we
should give an error.
Other than that, r=jfrancis.
Thanks Roy!
Assignee | ||
Comment 15•23 years ago
|
||
brendan: can you /sr=?
Whiteboard: waiting for /r= → waiting for /sr=
Comment 16•23 years ago
|
||
I am not the qa_contact for forms. Gerardo please reassign.
QA Contact: sujay → gerardok
Updated•23 years ago
|
Whiteboard: waiting for /sr= → r=jfrancis waiting for /sr=
Comment 17•23 years ago
|
||
sr=kin@netscape.com assuming you added the 'else' clause jfrancis asked for.
Assignee | ||
Updated•23 years ago
|
Whiteboard: r=jfrancis waiting for /sr= → r=jfrancis; /sr=kin; waiting for /a=
Comment 18•23 years ago
|
||
roy- can you put a new patch there?
Assignee | ||
Comment 19•23 years ago
|
||
Comment 20•23 years ago
|
||
a=blizzard on behalf of drivers for the trunk
Assignee | ||
Comment 21•23 years ago
|
||
checked-in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: r=jfrancis; /sr=kin; waiting for /a= → checked-in
Comment 22•23 years ago
|
||
Changing QA contact from gerardok to teruko. Teruko, is it possible for you to
verify this bug? Thanks.
QA Contact: gerardok → teruko
Reporter | ||
Comment 23•23 years ago
|
||
There seems to be some related problem with IME buffering.
In any TEXTAREA, if you click outside the textarea while you are typing in
Japanese, and kept typing, there is nothing entered because the cursor is not in
the textarea.
Then you click back where you wanted to type, and you can see strings that were
typed while the cursor was outside the textare.
Then you hit delete, and the string is entered again with the last character of
the string deleted.
2001070608 trunk still showing this behavior.
If appropriate, please file this as a separate bug.
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•