La imagen a continuación es una captura de pantalla de una publicación que estaba escribiendo en users.rust-lang.org.
Como se puede ver claramente, el campo de entrada está completamente roto. Y no es nuevo, ha estado sucediendo durante bastante tiempo.
Curiosamente, meta.discourse.org no parece tener ese problema. Entonces, ¿qué podría estar causando el problema?
Por alguna razón, las restricciones me impiden publicar la imagen real en el OP. Lo cual es bastante contraproducente, debo decir.
¿Cómo sabrás a qué me refiero si no puedo publicar una sola imagen que muestre el problema?
De todos modos, aquí puedo hacerlo en una publicación separada, así que aquí está:
Hola @jjpe 
bienvenido 
¿Podrías proporcionar más información sobre qué dispositivo y sistema operativo es, por favor?
No puedo reproducir esto. Estuve en el foro de Rust hace poco tanto en mi iPhone 15 Pro con iOS 18.0.1 como en mi Macbook con MacOS 15.01 Sequoia y el editor funciona como se esperaba.
Si solo está sucediendo en ese foro, pensaría que es un problema de un componente de tema o un plugin que a tu dispositivo/navegador no le gusta. 
quizás podrías intentar el modo seguro.
Hola, gracias
Claro, es un teléfono Samsung con Android. Que yo sepa, todos ejecutan el mismo software, aparte de los controladores.
Es importante tener en cuenta que solo tengo el problema con mi teléfono. El problema no aparece en mis otros dispositivos (portátil, ordenador de sobremesa).
Lo intentaré, pero no sería una solución si restablece el esquema de color a blanco. No me gusta que me cieguen
Así que el modo seguro parece tener un efecto distinto de cero.
Sin embargo, es difícil de medir, ya que el problema no se produce el 100% de las veces. Así que lo mejor por ahora, creo, es usar el sitio en modo seguro durante un tiempo y ver si el problema aparece.
Si no es así, esa es una dirección clara a seguir: un componente o plugin.
Resulta ser más complejo que un plugin o componente que cause el problema.
La captura de pantalla a continuación es de internals.rust-lang.org con el modo seguro habilitado.
Sin embargo, el cuadro de texto todavía tiene un tamaño incorrecto.
¿qué modelo y versión del sistema operativo? necesitamos poder reproducir esto para resolverlo.
¿Y qué navegador?
Sería el navegador Chrome.
La única configuración de accesibilidad que tengo habilitada es “Forzar habilitación de zoom”, pero eso no debería ser un factor aquí, ya que por defecto no hace nada. Simplemente me permite hacer zoom cuando de otra manera no sería posible.
[cita=“Lilly, publicación:7, tema:332668”]
¿Qué modelo y versión de sistema operativo? Necesitamos poder reproducir esto para resolverlo.
[/cita]
Supongo que me perdí esto antes.
El teléfono es un Samsung Galaxy S24+ con las últimas actualizaciones instaladas.
Es decir, Android 14 y OneUI 6.1
Estoy enlazando una publicación que hice sobre este problema en users.rust-lang.org.
¿Se ha hecho algo al respecto más de un mes después?
Ya hemos visto esto antes. Normalmente, la configuración del tamaño de fuente y del tamaño de pantalla en el dispositivo.
Es solo la salida web. Comprueba todas las influencias en tu pantalla de Chrome.
Ver la discusión aquí:
Sí, la cosa es que no hay ninguna si hablamos del navegador. Ese es solo Chrome para Android, que no tiene soporte para, por ejemplo, extensiones o complementos. Así que también volví a comprobar la configuración de accesibilidad, en particular el zoom del texto. Todo está configurado en los valores predeterminados.
Mientras tanto, también me he encontrado con el problema en el discurso de KDE, así que es definitivamente un problema con el propio discurso.
Curiosamente, responder aquí en meta no presenta este problema.
Pero es un problema, y uno que necesita ser resuelto porque simplemente rompe la experiencia del usuario.
Básicamente es lo mismo que ha molestado a Safari/iPadOS desde hace mucho tiempo. La razón principal por la que ya no uso Safari para Discourses, solo el Hub o PWA.
Pero lo más molesto es que no es constante. Pero sucede muy a menudo.
Ninguno de mis usuarios de Android se ha quejado de eso, sin embargo. Y creo que una gran parte de esos usuarios tiene un Samsung; tiene una cuota de mercado bastante buena en Finlandia.
Usar los sitios como PWA parece ayudar.
Pero eso es poco más que una solución temporal, por supuesto: las PWA siguen siendo aplicaciones web. Está justo en el nombre. Y como tales, todavía se ejecutan en un navegador, solo que sin la interfaz del navegador (por ejemplo, la barra de direcciones).
¿Quizás eso podría influir en este problema? ¿Quizás alguna propiedad de altura no se calcula correctamente en un navegador que tiene una interfaz de navegador real?
Pregunta de curiosidad completamente aleatoria, ¿cambia algo por casualidad el uso de una aplicación diferente como aplicación de teclado?
Honestamente, no lo sé. Ninguna alternativa a SwiftKey es aceptable para un uso serio para mí (lo he intentado, todas las alternativas apestan, o tal vez simplemente no me acostumbro a ellas, incluido GBoard), así que es un punto irrelevante.
Solo tengo curiosidad si de alguna manera es la combinación de teclado y navegador la que causa problemas, si usas temporalmente otra cosa, ¿persiste el problema?
Acabo de intentarlo.
Por desgracia, no puedo reproducirlo ahora mismo, en ninguna de las implementaciones de Discourse. Es decir, actualmente todas se comportan como esperaba.
Recibí una actualización del sistema hace un par de días y creo que entre los cambios hay algo relevante para este problema.
Aunque no puedo estar 100% seguro, si es cierto, el error estaría en el código del motor de Chrome o en el código de Android en algún lugar, en lugar de en Discourse en sí.
