Suggestions will hide when input combined character on IE

[KeitaMoromizato]

I tried input Japanese(Kanji) on IE 11. But suggestions hide when enter key press.

For combine character, Should ignore keyCode=229 in onKeyDown.

[moroshko]

Sorry, I'm not familiar with combined characters.
Does the issue exist only in IE11, or reproducible in Chrome as well?
Is the issue reproducible on the homepage examples?
Could you paste here the characters you type in the Autosuggest?

[KeitaMoromizato]

Reproduced on the this example.
I change code like this

const languages = [
  {
    name: 'にほん',
    year: 1972
  },
  {
    name: 'にほんご',
    year: 2000
  }
]

and type にほん(nihon) use Japanese Kana input mode.

This issue reproduce only IE 11. Because other browser fired onChange event (and re-update suggestion) after enter key pressed. Maybe it's IE bug, but keyCode=229 does not mean "Input finished", means "Inputting". So I think should not call closeSuggestions in this case.

[KeitaMoromizato]

FYI

const languages = [
  {
    name: 'にほん',
    year: 1972
  },
  {
    name: 'にほんご',
    year: 2000
  }
]

and

1. Typed にほん（nihon）
2. Press space key, and choose Kanji(にほん = 日本)
3. Press enter, decide Kanji
   => hide suggestions

[kivikakk]

See the keyCode spec:

2. If an Input Method Editor is processing key input and the event is keydown, return 229.

So keydown with keyCode 229 should be ignored, per this PR.

[moroshko]

@kivikakk @KeitaMoromizato Wouldn't it make sense to ignore keyCode 229 always, not just for Enter?

[KeitaMoromizato]

"KeyCode 229" event fire only from Enter pressed. So KeyCode 229 is part of enter pressed event. Therefore I wrote in Enter key handling section.

[moroshko]

v9.3.1 includes this fix.

@KeitaMoromizato @kivikakk Thanks for the contribution!

[cdeutsch]

I don't understand how you'd ever hit the fix

You'd only get to that line if keyCode was 13 right? It would never be 229 if you got there unless it's changing as soon as it's read.
¯_(ツ)_/¯
I'm not running into the issue or anything just confused how this fixed anything.

@KeitaMoromizato did you verify this fixed your problem?

[ekilah]

I am also a non-affected observer who just happened upon the comment in the code and was curious, and I agree with @cdeutsch that the fix is no longer doing anything, but it is probably not the fault of the author -

if you look at the PR's code, the library used to switch on event.key (i.e. case 'Enter':) whereas now it switches on event.keyCode (i.e. case 13:). my guess is that now that the keyCode is being used instead of the text 'Enter', things aren't broken anymore?