AddOnComma also does "AddOn<"

[bezoerb]

That's because < also has the keycode 188

[mbenford]

Nice catch. Thanks for reporting it. 👍

[bezoerb]

might be interested in the linked PR as well?

[mbenford]

I'll take a look at it.

[KostyaTretyak]

Also the same problem occurs if you are using not Latin keyboard layout.

[mbenford]

I tried to reproduce the problem, but I couldn't. My default keyboard layout is pt-BR, which makes the < key code to be 190. So I changed it to en-US and then the < char has the same key code as a comma, but the directive doesn't process any keystroke if some modifier is active (ctrl, alt, shift or meta). And so everything worked just fine. I also remembered that an issue pretty similar to this one was reported a long time ago: #35, and it was fixed by ignoring any keystroke if a modifier is on.

Could you provide a plunk showing your problem? Also, what keyboard layout are you using?

[KostyaTretyak]

My keboard uk-UA (Ukraine) and it processes the letter "б" (same key as comma but in Cyrillic)
Plunker

[bezoerb]

@KostyaTretyak thanks for the plunk ;)
@mbenford
I think this depends on the selected keyboard layout.
I'm using de-DE.
The duplicate keycodes for , and < is also mentioned here.

[mbenford]

I managed to emulate a de-DE keyboard, but even so I couldn't reproduce the problem. I used @KostyaTretyak's plunk and the comma char was processed as 188 while the < char was processed as 220. But I could reproduce the issue when using a uk-UA keyboard (apparently there's no comma key in that layout. Is that correct, @KostyaTretyak?).

Anyway, I don't think there exists one solution that addresses all keyboard layouts out there. It seems to me that a better approach would be to provide a way to override the directive's keydown handler (or a small part of it) so developers can deal with specific cases themselves.

[bezoerb]

@mbenford you may be right that there isn't the one solution. An approach could be to provide something like add-on-custom="{expression}".
Nevertheless i think the additional check provides more consistence/robustness to your api at almost no additional cost as it only secures the correct interpretation of the pressed key where possible.

[Varkh]

I'm also dealing with the same issue with Cyrillic keyboard as @KostyaTretyak. In Cyrillic keycode 188 is for the letter, and comma has keycode 191(? symbol at latin keyboard ). So when I press letter with code 188 new tag is created.

@mbenford comma is comma on each keyboard. I think the solution is to use ',' symbol instead of keycode.

P.S. Tried other tag libs, they handle such situation normally.

[kotmatpockuh]

I think that priority must be high!

[WiHHi-Z3-PuX]

same here, letter 'б' won't press, you can type your tag somewhere else, copy and paste it into tags input and it accepts it, so it has nothing to do with the character itself (well, obviously).
I really hope this gets fixed otherwise it becomes sort of unusable for Russian speaker oriented websites.

[mbenford]

This issue was selected to be spring-cleaned by a script. More information can be found here.

If anyone thinks this was a mistake and this issue should be reopened, please leave a message below explaining why. Before doing so, please consider reading the CONTRIBUTING file.