CKEditor écrit à l'envers

[rbailly]

Si j'écris "Bonjour" au clavier, j'obtiens "ruojnoB" à l'écran

Exemple : https://next-metascore.philharmoniedeparis.fr/fr/editor/xkXr?destination=/fr/creer

[semiaddict]

J'arrive à reproduire sous Chrome, mais pas sous Firefox.
Cela semble être lié à #567 (comment), et risque d'être particulièrement difficile à résoudre...

[semiaddict]

Pour le moment j'imagine les possibilités suivantes :

1. Attendre la résolution des problèmes de sélection dans les Shadow DOM

2. Éviter l'utilisation d'une iframe pour le rendu du player dans l'éditeur, mais cela implique de revoir l'usage des CSS externes pour éviter qu'elles surchargent celles de l'éditeur

3. Faire en sorte que l'édition du contenu textuel se fasse en dehors de l'iframe, en créant une copie du composant pour l'insérer dans l'éditeur

Malheureusement, aucune de ces solutions n'est optimale.
Je propose donc d'en discuter lors de notre prochaine réunion.

[semiaddict]

Une autre solution consiste à instancier CKEditor dans l'iframe de l'espace de travail, puis de déplacer la barre d'outils de CKEditor dans l'éditeur.
C'est le contraire de ce qui est fait actuellement; CKEditor est instancié dans le contexte de l'éditeur, mais avec un élément dans l'espace de travail (une div dans le composant en cours d'édition) comme cible.

Je viens de tester cette solution dans un contexte très simplifié (voir fichier HTML dans l'archive ci-jointe).
Cela semble bien fonctionner (au moins dans un contexte très simplifié) sur Chrome et Firefox avec la dernière version de CKEditor.
Cette solution a donc l’avantage de permettre l'utilisation de la dernière version de CKEditor 5 (ce qui nest pas le cas actuellement), mais nécessite un travail de remaniement non-négligeable pour arriver à charger CKEditor 5 avec les plugins personnalisés dans l'iframe de l'espace de travail.

ckeditor-load-in-iframe-test -.zip

[semiaddict]

Suite à plusieurs tests, j'ai plutôt l'impression que le problème est lié à la solution mise en place dans #575.
La mise à jour du model de données à chaque modification engendre en retour une mise à jour du contenu textuel, ce qui impacte la position du curseur dans le WYSIWYG.

[rbailly]

Suite à plusieurs tests, j'ai plutôt l'impression que le problème est lié à la solution mise en place dans #575. La mise à jour du model de données à chaque modification engendre en retour une mise à jour du contenu textuel, ce qui impacte la position du curseur dans le WYSIWYG.

Oui je pense que c'est vraiment lié car je n'avais pas constaté ce soucis avant la résolution du problème #575

[semiaddict]

J'ai résolu ce bug en "figeant" le composant en cours d'édition pour empêcher que les mises à jour du modèle de données engendrent des modifications dans le rendu HTML.

Je ne suis finalement pas sûr de la pertinence de désactiver certaines régions de l'éditeur lors de l'édition d'un contenu textuel.
La solution actuelle semble plutôt bien fonctionner, et permet de basculer vers l'onglet des comportements sans problème (le WYSIWYG se referme automatiquement, et le composant se défige).
De plus, le feature-request #577 devrait aider à faire comprendre à l'auteur qu'il est dans un mode d'édition spécial.

Qu'en pensez-vous ?