User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3) Steps to reproduce: Run the attached file. Enter 3 symbols. Actual results: The input field is empty. Expected results: The entered string should be visible

Thanks for reporting this issue. Can you please check if this works for you in Chrome, Internet Explorer, and a previous Firefox release?

It works for IE, and does not work for Chrome.

(In reply to irena.kull from comment #3) > It works for IE, and does not work for Chrome. Thanks, does this require specific hardware or Windows configuration to test? I don't have a chinese keyboard handy to reproduce.

Additionally, would you be able to check if this was working previously in Firefox? Our past releases are on ftp://ftp.mozilla.org/pub/firefox/releases/

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #4) > Thanks, does this require specific hardware or Windows configuration to > test? I don't have a chinese keyboard handy to reproduce. It doesn't matter what hardware keyboard you have. Type into the text field using any IME. As explained in bug 1164361, watching the input event will return the number of characters typed before composition has finished. Presumably what's happening here is that the script sees the value is greater than maxlength, and truncates it, even though Firefox already does so once composition has finished.

Maybe I'm testing this incorrectly but I can't seem to reproduce the behaviour you're describing. Can you please provide clearer steps to reproduce?

(In reply to irena.kull from comment #3) > It works for IE, and does not work for Chrome. Based on your user agent string, you're using IE 10. As I mentioned in bug 1164361, comment 1 and bug 1164361, comment 3, in IE 11 input is completely broken because the maxlength attribute restricts IME composition. (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #7) > Maybe I'm testing this incorrectly but I can't seem to reproduce the > behaviour you're describing. Can you please provide clearer steps to > reproduce? 1. Open attachment 8608747 [details] 2. Check “clear too long input via JavaScript” 3. Click the text field. 4. Using the Microsoft Pinyin New Experience Input Style IME, found under Chinese (Simplified, PRC) [1], attempt to type zhongwenma1 then press Enter. Expected results: The text field reads 中文码 For comparison, paste the following into the location bar and press Enter, then try the STR there: data:text/html,<input type="text" maxlength="3"> Actual results: Composition ends prematurely. The text field is empty. [1] http://windows.microsoft.com/en-us/windows/type-chinese-japanese-character-languages http://windows.microsoft.com/en-us/windows-8/input-method-editors

Thank you for clarifying the steps to reproduce. I can see this now but for what it's worth I can reproduce this at least as far back as Firefox Nightly 14.0a1. I'm guessing this is something we probably never supported properly.

I found it by mozregression and testing.

Also, if I changed the oninput to compositionstart / compositionupdate / compositionend in attachment 8608747 [details], it seems works fine.

According to the testcase, our current behavior is valid. composing string can be retrieved by web apps with checking <input>.value. So, trying to omit composing string by the web app itself is a bug. web apps shouldn't modify <input>.value when InputEvent.isComposing is true. And also the input event behavior of Gecko completely conforms to the spec.