Xterm.js: altgr+num imprime un mauvais caractère sur le clavier français azerty

Peut être lié à https://github.com/xtermjs/xterm.js/issues/2151

Tout le code de gestion des événements clavier se trouve dans ce fichier :

https://github.com/xtermjs/xterm.js/blob/29e53c9c1171e4e3fce7c7d172cd8f182b13aece/src/common/input/Keyboard.ts

@Tyriar Quel type d'aide recherchez-vous ? (Au cas où j'en serais capable.)

@willemavjc, quelqu'un doit enquêter sur la raison pour laquelle le caractère supplémentaire est imprimé (dans Keyboard.ts), car l'éditeur de texte de Monaco ne le fait pas, nous devrions également pouvoir éviter le problème. Il y a peut-être autre chose sur KeyboardEvent que nous devons examiner ?

J'ai pu reproduire cela sur toutes les touches mortes qui nécessitent l'utilisation de la touche AltGr, y compris sur le clavier BÉPO , qui est un clavier DVORAK français. Il y a probablement un return ou un break manquant quelque part qui indiquerait à xterm.js d'arrêter d'essayer d'identifier la clé s'il s'agit d'une clé morte. Il est à noter que les touches mortes qui n'utilisent pas la touche AltGr fonctionnent toujours parfaitement (tant pour AZERTY que pour BÉPO).

Je ne connais pas le langage TypeScript mais la cause exacte peut être trouvée en déboguant le fichier Keyboard.ts

De plus, je viens de découvrir que taper Ctrl+Alt puis la touche fonctionne bien, car AltGr est une sorte d'alias pour Ctrl+Alt sous Windows.

Récapituler:

| Séquence de touches | Attendu | Réel |
| --- | --- | --- |
| Ctrl+Alt+2 puis Espace | ~ | ~ |
| AltGr + 2 puis Espace | ~ | é~ (é apparaît sur AltGr + 2, ~ apparaît sur Espace) |
| Ctrl+Alt+7 puis Espace | ` | ` |
| AltGr + 7 puis Espace | ` | è` (è apparaît sur AltGr + 7, ` apparaît sur Espace) |

Il y a certainement quelque chose qui ne va pas avec la façon dont la touche AltGr est gérée

@utybo Eh bien, si vous voulez aider à creuser cela (nous ne pouvons pas car nous utilisons tous des mises en page dérivées de QWERTY - anglais et allemand), peut-être que cela est utile https://w3c.github.io/uievents/tools/key-event-viewer .html. Nous nous appuyons un peu sur les éléments rapportés des événements qui y sont présentés, sans savoir encore comment AltGr sur AZERTY joue dans cela.

@jerch

AltGr + 2 (1 à 6) puis Espace (7 à 11) ce qui donne ~

Ctrl + Alt + 2 (1 à 6) puis Espace (7 à 11) ce qui donne ~

AltGr + 7 (1 à 6) puis Espace (7 à 11), ce qui donne le caractère backtick `

Ctrl + Alt + 7 (1 à 6) puis Espace (7 à 11) ce qui donne le même caractère

À des fins de test, je pense que la bonne touche Alt sur les claviers QWERTY agit comme la touche AltGr sur les keymaps AZERTY/BEPO, mais je peux me tromper

@utybo Donc cette page rapporte les valeurs correctes ? Si c'est le cas, le problème est probablement de notre côté (déjà pensé cela en premier lieu). Eh bien, dans Keyboard.ts, il se passe un peu de magie et pire encore, presque pas de commentaires. C'est un peu difficile de commencer quelque part sans casser autre chose. Si vous êtes toujours prêt, allez-y :)

Curieusement, je suis incapable de reproduire cela en utilisant les sources. Cela fonctionne parfaitement bien lorsque vous utilisez le serveur Web local lancé avec fil. Peut-être que VS Code utilise une ancienne version ?

@Tyriar Pour info , comme #2151 ne semble se produire que dans vscode.

J'essaie ce problème maintenant sur mon PC de travail et cela semble bien (en utilisant le clavier à l'écran)

On dirait que le clavier à l'écran utilise simplement Ctrl + Alt au lieu d'AltGraph, donc la sortie est différente de celle du clavier réel

Il est également intéressant de noter que lorsque le clavier à l'écran est activé, je ne peux pas saisir du tout ~ en utilisant le clavier physique, il écrit simplement é dans le terminal de VS Code.

@utybo je suis sûr que je l'ai testé à la maison à l'aide du clavier à l'écran et que je pourrais le reproduire 🤔

Même avec un clavier physique, cela fonctionne parfois parfaitement, mais la plupart du temps, le bug est là. Toute cette question est un peu déroutante.

Même avec un clavier physique, cela fonctionne parfois parfaitement, mais la plupart du temps, le bug est là. Toute cette question est un peu déroutante.

S'il vous plaît essayez de réduire les circonstances - peut-être est-ce lié à la façon dont vous démarrez vscode ? Cela ne se produit-il que dans le terminal ou l'éditeur affiche-t-il le même comportement étrange ? Quel OS + version ? La disposition du clavier est-elle correctement configurée dans le système d'exploitation ?

Honnêtement, je n'en ai aucune idée. Parfois, le problème n'existe tout simplement pas, mais c'est assez rare. Je suis capable de reproduire cela de manière fiable sur mes deux PC :

• Windows 10 (10.0.18362.418) avec VS Code 1.39.2, avec la mise en page française (France)
• Windows 10 (10.0.18362.10024) avec VS Code 1.39.2 et VS Code Insider 1.40.0-initié avec la mise en page française (France)

La disposition du clavier est celle de base de Windows.

@jerch Comme indiqué dans https://github.com/microsoft/vscode/issues/82489, il n'apparaît que dans la section Terminal de l'éditeur VSCode. Aucun problème dans la section Code ou ailleurs dans l'éditeur. Quel que soit le shell sous-jacent (PowerShell, git-bash, etc.), il est affecté. Et ce même shell en dehors de VSCode fonctionne parfaitement bien.

@Tyriar Je ne sais pas comment aborder cela - cela semble être un problème marche/arrêt aléatoire. Puisqu'un ordinateur est toujours une machine déterministe, il y a une cause cachée à mon humble avis.

@willemavjc , @utybo Pouvez-vous confirmer que cela ne se produit jamais dans la démo xterm.js, uniquement dans le terminal vscode ?

Je confirme que cela ne se produit jamais dans la démo xterm.js et uniquement dans le terminal vs code, même lorsque vous essayez vraiment avec des choses comme des keymaps alternatives. @jerch

En ce qui concerne le "problème d'activation / désactivation aléatoire", je dirais que le problème se produit 90% du temps sur mon triste. Sachez simplement que vous ne pouvez pas utiliser le clavier à l'écran pour essayer ceci (il gère AltGr différemment): pour autant que j'aie essayé, il doit s'agir du clavier AZERTY réel sur votre clavier.

Essayé sur un PC domestique, cela semble se produire 100% du temps à la fois sur vscode et sur la démo xterm.js

Le fait de ne pas utiliser l'événement input pourrait-il être un autre problème ? Les 2 premiers sont en appuyant sur alt, le 3ème est 2 , le 4ème est l'espace :

Ce premier événement semble étrange, mais je ne pense pas que cela causerait ce problème.

Si key est la propriété utilisée par xterm.js, cela s'explique comme la propriété key de keydown lorsque vous appuyez sur AltGr + 2 n'est pas correct dans Chromium.

Comparez avec FF, qui génère une clé dead dans ce cas

Je pense que nous devons passer à input pour résoudre ce problème correctement, tout comme dans https://github.com/xtermjs/xterm.js/issues/469

Un peu pour résumer les choses :

Environnement utilisé :

• Machine : Surface Pro 6 avec clavier AZERTY
• Version du système d'exploitation : Microsoft Windows (Pro) version 1903 (version du système d'exploitation 18362.449)
• Version PowerShell : 5.1
• Version VSCode : 1.39.2

AltGraph 2 Space pour obtenir ~

• Applications x86/x64 (Office, etc.) : Réussite
• Native PowerShell : Passage
• Git bash : Réussir
• Éditeur VSCode : Passage
• Terminal VSCode (PowerShell) : Échec

Test complémentaire avec clavier AZERTY à l'écran :

• Terminal VSCode (PowerShell) : Passage

Test supplémentaire avec la démo xterm.js :

• Clavier physique : Échec
• Clavier à l'écran : réussite

L'utilisation du site Web Keyboard Event Viewer donne les mêmes captures d'écran que @utybo a indiqué ici . Tests effectués avec le navigateur Brave (c'est-à-dire Chromium).

L' instruction AltGraph dans le clavier à l'écran est traité comme Alt combinaison Control et Alt .

@Tyriar @jerch @rebornix Ne serait-ce pas l'indice facile au final ? Mapper AltGraph comme Control plus Alt dans xterm.js aussi ?

@willemavjc Je pense que nous avons identifié la cause est que nous n'utilisons pas d'entrée (de plus Chrome pourrait avoir un bogue où il ne signale pas la clé comme morte sur keydown ), le correctif n'est pas super trivial car cela impliquait de changer la façon dont toutes les entrées sont traitées, ce qui nécessite beaucoup de vérifications.

@Tyriar D'accord. Si vous avez besoin d'une sorte de test ou autre, faites-le moi savoir. Je serai heureux de vous aider.

Je pense que notre code source d'événements clés est coincé entre les anciens paradigmes (un très mauvais hack de keypress vs keydown jonglerie, provient de l'époque où les navigateurs faisaient tout leur propre chose) et des cas particuliers nous avons besoin d'un envoi approprié de la clé du terminal.
Devinez qu'il est temps pour une réécriture propre avec de meilleurs documents (doh, toutes ces constantes magiques sans aucun commentaire lol). Je ne sais pas non plus si input mappe tous les bits nécessaires ou si nous avons encore besoin de keydown cales - cela nécessitera de sérieux tests aller-retour. Comme je ne peux pas reproduire le problème, des preneurs pour se salir les mains ?

Je ne peux plus le reproduire 🤔 Quelqu'un d'autre a-t-il encore ce problème ?

Je viens d'essayer sur vscode insider et xterm.js et j'ai toujours ce problème.

J'ai ce problème aussi. J'espère toujours une solution... une telle douleur pour les locuteurs étrangers.

Si quelqu'un veut s'attaquer à cela, veuillez consulter mon dernier commentaire dans PR #2976.