Japanese chars are not written correctly in textitem when using validate on change

[karankhokhani]

SmartGWT version 3.0
Browser FF

Hiragana characters in the Japanese language are not written correctly in the text item when its validated on change using a custom validator.


----------------------------------------
To setup Japanese keyboard

1. Go to 'Region and Language'
2. Go to the 'Keyboards and Language' tab
3. Click Change keyboards...'
4. On the 'General' tab click 'Add'.
5. Navigate to Japan and select Japanese and Microsoft IME options
6. Click OK, you should have those options in your list now
7. Go to the Language bar tab in the same panel, and check 'Docked in the Taskbar' (that's where I have it)
8. The language bar lets you select Japanese language by clicking on the EN, then switch to Japanese
9. Change the keyboard input then by clicking on the capital A and changing it to Hiragana(あ)
10. You should be typing in Japan now.
11. If you load the 'Onscreen keyboard' you should be able to see where the keys are and what your keyboard is set to.

------------------------------------------------------

k + o means こ in Japanese. The character is written correctly (see 1.png) when the valid state remains true, that is, valid. However, when written causing the valid state to be false (4.png) or from false to true (2.png and 3.png), the letter don't appear correctly.

Sample code

import com.google.gwt.core.client.EntryPoint;
import com.smartgwt.client.widgets.form.DynamicForm;
import com.smartgwt.client.widgets.form.fields.TextItem;
import com.smartgwt.client.widgets.form.validator.CustomValidator;

public class TextItemTest implements EntryPoint {
public void onModuleLoad() {

DynamicForm form = new DynamicForm();

TextItem item = new TextItem();
item.setTitle("JapaneseChar");
item.setValidateOnChange(true);

CustomValidator validator = new CustomValidator()
{

@Override
protected boolean condition(Object value)
{
if(value == null || ((String)value).length() == 0 || ((String)value).length() > 10)
return false;
else
return true;
}
};
item.setValidators(validator);

form.setFields(item);
form.draw();
}

}

Please let me know if you need any more info.

This appears to be a focus issue in smartgwt. Is there a fix or workaround for this?

[karankhokhani]

adding more images ...

[Isomorphic]

This looks to be some kind of native bug in Firefox, or between Firefox and Windows, that we are unlikely to be able to correct.

However, you should try a new version of Firefox, and also a current version of SmartGWT (ideally 4.1 but *at least* 3.1) to see if it corrects the issue somehow.

If it doesn't, you will probably need to disable validateOnChange to work around the Firefox issue. Note that interrupting the user's typing to tell them the value is too long is generally considered bad practice - instead, most sites with a length limit will show the current number of characters separately (in a place that doesn't cause the input field to move around if it's updated) and style that area red if the length has been exceeded.

[karankhokhani]

I am using FF 26.0. I tried it with 3.1 too but still the same. There is no other workaround other than disabling validateOnChange? We use validateOnChange at a lot of places for different reasons. The one in the sample code was just an example.

[Isomorphic]

As far as we can tell, this wouldn't affect validateOnChange in general, just use of validateOnChange while the user is currently typing in a text field. As we covered, using validateOnChange in this way is typically bad UI anyway, so you might have a win-win situation of creating a better UI while also working around this Firefox issue.

Separately, we'll see if we can isolate what triggers the Firefox bug - if it's just a blur() on the element, or some other problem. That might lead to a bug report which will hopefully be addressed quickly.

[Isomorphic]

Just a note that we've tracked this to a change in the series of events Firefox sends in the case of IME input. We're not sure between which Firefox versions the event series changed, but we think we see a moderately complicated workaround which we will investigate.

However, you should update to a more recent version if this workaround turns out to be important for you. This new event handling strategy, if feasible, will be applied to at least 5.0 and 4.1, but possibly not further back.