L’image ci-dessous est une capture d’écran d’un article que j’étais en train d’écrire sur users.rust-lang.org.
Comme on peut le voir très clairement, le champ de saisie est tout simplement complètement cassé. Et ce n’est pas nouveau, cela fait un bon moment que ça dure.
Étrangement, meta.discourse.org ne semble pas avoir ce problème. Alors, qu’est-ce qui pourrait causer ce problème ?
Pour une raison quelconque, les restrictions m’empêchent de publier l’image réelle dans le message d’origine. Ce qui est assez contre-productif, je dois dire.
Comment saurez-vous ce que je veux dire si je ne peux pas publier une seule image montrant le problème ?
Quoi qu’il en soit, j’ai le droit de le faire ici dans un message séparé, alors la voici :
1 « J'aime »
Salut @jjpe 
bienvenue 
Pouvez-vous fournir plus d’informations sur l’appareil et le système d’exploitation s’il vous plaît ?
Je ne parviens pas à reproduire cela. J’étais justement sur le forum Rust moi-même sur mon iPhone 15 Pro sous iOS 18.0.1 et sur mon Macbook sous MacOS 15.01 Sequoia, et l’éditeur de texte fonctionne comme prévu.
Si cela ne se produit que sur ce forum, je penserais qu’il s’agit d’un problème de composant de thème ou de plugin que votre appareil / navigateur n’aime pas. 
vous pourriez peut-être essayer le mode sans échec.
3 « J'aime »
Salut, merci
Bien sûr, c’est un téléphone Samsung sous Android. Autant que je sache, ils fonctionnent tous avec le même logiciel, à part les pilotes.
Il est important de noter que je n’ai ce problème qu’avec mon téléphone. Le problème n’apparaît pas sur mes autres appareils (ordinateur portable, ordinateur de bureau).
Je vais essayer, mais ce ne serait pas une solution si cela réinitialise le schéma de couleurs au blanc. Je n’aime pas être aveuglé
Ok, le mode sans échec semble avoir un effet non nul.
Cependant, il est difficile de l’évaluer car le problème ne survient pas 100 % du temps. La meilleure chose à faire pour l’instant est donc d’utiliser le site en mode sans échec pendant un certain temps, et de voir si le problème se manifeste.
S’il ne se manifeste pas, alors c’est une direction claire à explorer : un composant ou un plugin.
Il s’avère que c’est plus complexe que certains plugins ou composants causant le problème.
La capture d’écran ci-dessous provient de internals.rust-lang.org avec le mode sans échec activé.
Pourtant, la zone de texte est toujours mal dimensionnée.
1 « J'aime »
quel modèle et quelle version du système d’exploitation ? nous devons être en mesure de reproduire cela pour le comprendre.
1 « J'aime »
Et quel navigateur ?
1 « J'aime »
Ce serait le navigateur Chrome.
La seule option d’accessibilité que j’ai activée est « Forcer l’activation du zoom », mais cela ne devrait pas être un facteur ici, car par défaut, elle ne fait rien. Elle me permet simplement de zoomer alors que ce ne serait pas possible autrement.
Je suppose que j’ai manqué ça avant.
Le téléphone est un Samsung Galaxy S24+ avec les dernières mises à jour installées.
C’est-à-dire Android 14 et OneUI 6.1
Je fais un lien croisé vers un article que j’ai publié à ce sujet sur users.rust-lang.org.
Plus d’un mois plus tard, quelque chose a-t-il été fait à ce sujet ?
Nous avons déjà vu cela. Habituellement, les paramètres de taille de police et de taille d’affichage sur l’appareil.
C’est juste une sortie web. Vérifiez toutes les influences sur votre affichage Chrome.
Voir la discussion ici :
Oui, le fait est qu’il n’y en a aucune si nous parlons du navigateur. C’est juste Chrome pour Android, qui n’a aucun support pour les extensions ou les plugins. J’ai donc également revérifié les paramètres d’accessibilité, en particulier le zoom du texte. Tout est réglé sur les valeurs par défaut.
Pendant ce temps, j’ai également rencontré le problème sur le forum KDE, c’est donc certainement un problème avec le forum lui-même.
Étrangement, répondre ici sur meta ne présente pas ce problème.
Mais c’est un problème, et il doit être résolu car il gâche l’expérience utilisateur.
Essentiellement, c’est la même chose qui dérange Safari/iPadOS depuis longtemps. La raison principale pour laquelle je n’utilise plus Safari pour les Discourses, seulement le Hub ou PWA.
Mais le plus agaçant est que ce n’est pas constant. Mais cela arrive très souvent.
Aucun de mes utilisateurs Android ne s’en est plaint, cependant. Et je pense qu’une bonne partie de ces utilisateurs ont un Samsung — il a une part de marché assez importante en Finlande.
L’utilisation des sites comme PWA semble effectivement aider.
Mais ce n’est guère plus qu’une solution de contournement, bien sûr - les PWA sont toujours des applications web. C’est dans le nom même. Et en tant que telles, elles s’exécutent toujours dans un navigateur, juste sans l’habillage du navigateur (par exemple, la barre d’adresse).
Alors peut-être que cela pourrait jouer un rôle dans ce problème ? Peut-être qu’une propriété de hauteur n’est pas calculée correctement dans un navigateur qui a un véritable habillage de navigateur ?
Question de curiosité totalement aléatoire, est-ce que l’utilisation d’une application différente comme application de clavier change quelque chose par hasard ?
Honnêtement, je ne sais pas. Aucune alternative à SwiftKey n’est acceptable pour une utilisation sérieuse pour moi (j’ai essayé - toutes les alternatives sont nulles, ou peut-être que je ne peux tout simplement pas m’y habituer, y compris GBoard), donc c’est un peu un point discutable.
Je suis juste curieux de savoir si c’est la combinaison du clavier et du navigateur qui pose problème, si vous utilisez temporairement autre chose, le problème persiste-t-il ?
1 « J'aime »
Je viens d’essayer ça.
Malheureusement, je ne peux pas le reproduire en ce moment, sur aucun des déploiements de discourse. C’est-à-dire qu’ils se comportent tous comme je m’attendrais à ce qu’ils le fassent.
J’ai reçu une mise à jour système il y a quelques jours, et je pense que parmi les changements se trouve quelque chose de pertinent pour ce problème.
Bien que je ne puisse pas être sûr à 100%, si le bug est avéré, il se situerait quelque part dans le code du moteur Chrome ou dans le code Android plutôt que dans discourse lui-même.