1272250 - Changing size of text input element during IME input, disrupts IME input.

Status: RESOLVED DUPLICATE of bug 1162818

(Core :: Layout: Form Controls, defect)

Description

[Jarra McIntyre]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

On (at least) Firefox 46.0.1 running on Windows 10 (64bit, Japanese version), while the user is performing IME input (Japanese specifically), matching the value of the input against a unicode regular expressions breaks the IME input. Specifically, it causes behavior equivalent to having accepted the current IME input candidate, even when the user is only part way through their input.

If I call clone() on the string before matching the regular expression, the problem is fixed and the IME input is unaffected.

Specifically I have the following JS code (simplified), which works on other browsers and past versions of Firefox on Windows 8:

function setupTextValidation(input,rule,...other arguments) {
  var $input = $(input);
  ...
  function validate() {
    ...
    var valid = $input.val().match(rule);
    if(!valid) {
      ...handle case input is invalid. Does not in any way modify (or even reference) the input value or element...
    } else validationResult |= mask;
    toogleSubmit();
  }
  $input.on('input',validate);
  validate();
}

Where rule is the following regular expression:
/^([A-Za-z \u3400-\u9FFF\uF900-\uFAFF\u3041-\u309F\u30A0-\u30FF\u31F0-\u31FF\u3000\u3005]|[\uD840-\uD843][\uDC00-\uDFFF]){1,60}$/

I also call setupTextValidate() on other inputs using different regular expressions. I have confirmed that the regular expression:
/^[\w.]{5,128}$/ does _NOT_ affect the IME state.

If I change the line: 'var valid = $input.val().match(rule);', to: 'var valid = $input.val().clone().match(rule);' the problem is resolved and IME input is no longer effected. That is cloning the string resolves the issue.


Actual results:

IME input on a text input is interrupted on (at least) Firefox 46.0.1 on Windows 10 (64 bit) when executing (the equivalent to) the following Javascript:

$('#myinput').val().match(/^([A-Za-z \u3400-\u9FFF\uF900-\uFAFF\u3041-\u309F\u30A0-\u30FF\u31F0-\u31FF\u3000\u3005]|[\uD840-\uD843][\uDC00-\uDFFF]){1,60}$/)

IME input is not interrupted when executing (the equivalent to) the following Javascript:

$('#myinput').val().clone().match(/^([A-Za-z \u3400-\u9FFF\uF900-\uFAFF\u3041-\u309F\u30A0-\u30FF\u31F0-\u31FF\u3000\u3005]|[\uD840-\uD843][\uDC00-\uDFFF]){1,60}$/)


Expected results:

The behavior of:

$('#myinput').val().match(/^([A-Za-z \u3400-\u9FFF\uF900-\uFAFF\u3041-\u309F\u30A0-\u30FF\u31F0-\u31FF\u3000\u3005]|[\uD840-\uD843][\uDC00-\uDFFF]){1,60}$/)

and:

$('#myinput').val().clone().match(/^([A-Za-z \u3400-\u9FFF\uF900-\uFAFF\u3041-\u309F\u30A0-\u30FF\u31F0-\u31FF\u3000\u3005]|[\uD840-\uD843][\uDC00-\uDFFF]){1,60}$/)

should be identical as per other major browsers. That is matching the value of a text input should not mutate the value in any way.

Comment 1

[Jarra McIntyre]

Quick Summary: Above bug report is incorrect. Problem is that in Firefox 46.0.1 on Windows 10 resizing a text input (by setting the style 'display: none' on a span next to it), causes IME input to be interrupted, making it almost practically impossible for the user to enter their desired input.

---

Correction 1: '$('#myinput').val().clone()' should read 'clone($('#myinput').val())' with clone simply defined as: function clone(str) { return JSON.parse(JSON.stringify(str)); }

Correction 2: The above mistake lead me to believe cloning the string was solving the problem (in fact this was just causing an error). In fact, after further investigation the problem is that when the user enters valid input I set the style 'display: none' on a span next to the text input. This in turn causes the input to resize, which disrupts the IME input. As the regular expression shown validates partial input, the input is resized during user input, which at least in Firefox 46.0.1 on Windows 10 cause the IME input to be interrupted. (For example entering odanobunaga and pressing space then enter should result in the string 織田信長 but instead results in the string: おｄあ信長) as IME input was interrupted between the second and third character.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This should've already been fixed by the fix of bug 1162818. If you can reproduce this bug even in these days, please file a new bug with a test case.