Closed Bug 286842 Opened 19 years ago Closed 17 years ago

Input element incorrectly cleared with IME mid-input

Categories

(Firefox :: General, defect)

1.5.0.x Branch
x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: fnjordy, Unassigned)

References

()

Details

(Keywords: intl)

Attachments

(1 file)

119.89 KB, application/x-shockwave-flash
Details
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

This is my version of an auto-complete input control, the same problem can be
seen on Google Suggest Japan - http://www.google.co.jp/webhp?complete=1&hl=ja

You type into a normal text control and a popup window will appear beneath the
control listing terms that match.  Its behaviour is similar to that of the
address bar.

These controls work fine in Latin text in Firefox, and all text in MSIE and
Opera 7.54/8 beta.

Reproducible: Always

Steps to Reproduce:
1.  Enter in Japanese し (shi), the character can be copy & pasted.
2.  Select a result using the mouse or keyboard, there is only one for my link,
"しろ".
Actual Results:  
The input form field element is empty.

Expected Results:  
The element should be updated with the autocomplete result, e.g. "しろ".

The functionality works fine with latin text, which highlights the problem might
be due to the handling of a keyboard event from the IME.  I've tested normal
Unicode updating of an input control and that works fine:

http://fnjordy.cus.org.uk/auto/mozbug/

If the JavaScript for the auto-complete is modified before the input value is
updated the problem is not seen.  To do this change the code around line 332:

...
{
alert('moo!');
this.obj.value = results[0][1];
if (this.obj.createTextRange) {
... 

This again highlights a timing issue with updating the control's value.

The only way to detect updating of input control is via repeat polling from a
timeout.

The event handlers onkeydown(), onkeypress(), and onkeyup() are not consistently
called for IME input.  For example entering あか will generate two events, one
for each character, but entering しろ should raise five, 's', 'sh', 'し', 'r',
and 'ろ' if this method is to be of any use.
Some additional information, the functions to update the input element occur
20ms after the actual key press, the listed page also has one control that will
wait 1000ms for a total ot 1010ms till the element be updated.

Using the Venkman JavaScript debugger (0.9.84) if I insert a breakpoint at line
333 I can see the problem, if I insert a breakpoint a line 332 just before the
update and step through I do not.

 B  332          this.obj.value = results[0][1];
 B  333          if (this.obj.createTextRange) {
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Reproduced with Firefox 1.5 beta 1, captured a Wink flash movie showing the bug:

http://fnjordy.cus.org.uk/auto/mozbug/jpmozbug.html (120KB)

What should happen is the Japanese text should get filled in the input element.
The problem could also be just IME interaction on Windows, with a non-finished
kana JavaScript might actually update the element correctly but the IME wipes
out the value because it was not completed.
Attached file flash reproduction
Occurs in Firefox, but not Internet Explorer, also reporting to Google Labs.
Keywords: intl, js1.6
Summary: Input form field value is cleared after updating with Unicode from a timeout → Input element incorrectly cleared with IME mid-input
Assignee: firefox → nobody
Keywords: js1.6
Severity: normal → major
Version: unspecified → 1.5 Branch
Steve-o, the link no longer works and it seems like Google Suggest Japan loads the query when you click on an item from the drop down now. This has probably changed since the bug was filed. Do you have a reproducible testcase that happens in Firefox 2.0.0.3 which you can upload or link to here?
Whiteboard: CLOSEME - 4/15
With no updates from the reporter, I'm going to close this bug as "works for me". If you can reproduce this using Firefox 2.0.0.3 with a clean profile, please reopen.

http://kb.mozillazine.org/Profile_Manager
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Whiteboard: CLOSEME - 4/15
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: