下の画像は、users.rust-lang.org で投稿を作成していたときのスクリーンショットです。
ご覧の通り、入力フィールドが完全に壊れています。これは新しい問題ではなく、かなり前から続いています。
奇妙なことに、meta.discourse.org ではその問題は発生していないようです。では、何が原因なのでしょうか？
なぜか制限によりOPに実際の画像を投稿できません。これは非常に非生産的だと言わざるを得ません。
問題を示す画像を投稿できない場合、私が何を意味するのかどうやってわかるのでしょうか？
とにかく、ここでは別の投稿で許可されているので、以下に示します。
「いいね！」 1
こんにちは、@jjpe さん 
ようこそ 
お使いのデバイスとOSについて、もう少し詳しい情報を教えていただけますか？
再現できませんでした。私もつい先ほど、iPhone 15 Pro iOS 18.0.1 と Macbook MacOS 15.01 Sequoia の両方でRustフォーラムにアクセスしましたが、コンポーザーは期待どおりに動作していました。
もしそのフォーラムでのみ発生しているのであれば、お使いのデバイス/ブラウザが好まないテーマコンポーネントまたはプラグインの問題である可能性があります。 
セーフモードを試してみてはいかがでしょうか。
「いいね！」 3
こんにちは、ありがとうございます:)
はい、AndroidのSamsung製スマートフォンです。ドライバ以外はすべて同じソフトウェアで動作していると思います。
この問題は私のスマートフォンでのみ発生することに注意してください。他のデバイス（ラップトップ、デスクトップ）では問題は発生しません。
試してみますが、カラースキームが白にリセットされるようでは解決策になりません。目がくらむのはあまり好きではありません:)
セーフモードにはゼロではない効果があるようです。
ただし、問題が100％発生するわけではないため、その効果を測定するのは困難です。したがって、現時点での最善策は、しばらくの間セーフモードでサイトを使用し、問題が発生するかどうかを確認することだと思います。
もし発生しないのであれば、それは明確な方向性となります。コンポーネントまたはプラグインを調査することです。
問題の原因がプラグインやコンポーネントよりも複雑であることが判明しました。
下のスクリーンショットは、セーフモードが有効になっている internals.rust-lang.org からのものです。
それでもテキストボックスのサイズが間違っています。
「いいね！」 1
どのモデルでOSのバージョンはいくつですか？これを再現できなければ、原因を特定できません。
「いいね！」 1
そして、どのブラウザですか？
「いいね！」 1
それはChromeブラウザでしょう。
有効にしているアクセシビリティ設定は「ズームの強制有効化」のみですが、これはデフォルトでは何も行わず、ズームできない場合にズームを可能にするだけなので、ここでは関係ないはずです。
これを見落としていたようです。
お使いの携帯電話はSamsung Galaxy S24+で、最新のアップデートがインストールされています。
つまり、Android 14とOneUI 6.1です。
この問題について、users.rust-lang.org に投稿した内容をクロスリンクします。
1ヶ月以上経ちましたが、この件について何か進展はありましたか？
以前にも見られた現象です。通常はデバイスのフォントサイズと表示サイズの設定が原因です。\n\nこれは単なるWeb出力です。Chromeの表示に影響を与えるすべての設定を確認してください。\n\nこちらで議論をご覧ください。\n\nSuch a tiny window to edit here on a cell phone
ええ、ブラウザの話であれば、何もありません。これはAndroid版Chromeで、拡張機能やプラグインなどのサポートはありません。そのため、アクセシビリティ設定、特にテキストズームも確認しました。すべてデフォルト値に設定されています。
その間、KDEディスコースでも問題が発生しました。これは間違いなくディスコース自体の問題です。
奇妙なことに、ここでメタに応答してもこの問題は発生しません。
しかし、これは問題であり、ユーザーエクスペリエンスを損なうため、解決する必要があります。
要するに、これはSafari/iPadOSが長い間悩まされてきたことと同じです。私がもうDiscourseでSafariを使用しない主な理由であり、HubまたはPWAのみを使用しています。
しかし、最も腹立たしいのは、それが一定ではないことです。しかし、それは本当に頻繁に起こります。
Androidユーザーからは、そのことについて苦情はありません。そして、それらのユーザーのかなりの部分がSamsungを持っていると思いますが、フィンランドではかなりの市場シェアを持っています。
サイトをPWAとして使用すると、確かに役立ちます。
しかし、それはもちろん、ほとんどワークアラウンドにすぎません。PWAは依然としてWebアプリです。名前そのものにそれが表れています。そして、そのように、それらはブラウザのクローム（例：アドレスバー）なしで、依然としてブラウザで実行されます。
では、それがこの問題に関係しているのでしょうか？実際のブラウザのクロームを持つブラウザでは、何らかの高さのプロパティが正しく計算されていないのでしょうか？
全くの好奇心からの質問ですが、キーボードアプリとして別のアプリを使用すると、何か変わることはありますか？
正直なところ、わかりません。真面目な用途では、SwiftKey以外は受け入れられません（試しましたが、GBoardを含め、他の代替手段はすべてひどいか、慣れることができませんでした）。そのため、あまり意味のない点です。
キーボードとブラウザの組み合わせが原因である可能性はありますか？一時的に別のものを使用した場合、問題は継続しますか？
「いいね！」 1
それを試したばかりです。
残念ながら、現在、どのディスコースデプロイメントでも再現できません。つまり、現在、すべてが期待どおりに動作しています。
数日前にシステムアップデートがあり、その変更の中にこの問題に関連するものがあると考えています。
100％確信はできませんが、もしそうであれば、バグはディスコース自体ではなく、ChromeエンジンコードまたはAndroidコードのどこかにあるでしょう。